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l,,r llw WIT Computer- Aided Dawn Project. His 
activities include: 

• directing development of an inleerated svstent of pro- 
gram development, integration, and tesring tools for 
production ot large-scale military programs: 
creating and directing the development of the APT 
system for automatic programming of numerically 
controlled machine tools, now an international stan- 
dard: and 

leading the MIT Computer-Aided Design Project, 
including research and development in language the- 
oi v. language design, generalized compiler construc- 
tion. computer graphics hardware and software, and 
design applications. 

I Of In 1 Tins 0l r . LCil WaS loumJcd - Ross was president from 
.. ( ) ° 1 >75 and ls ium s’hairman emeritus of the hoard of 
directors. 

He was an organizer and participant in the NATO Soft- 
ware Engineering Conferences in Germany ( 1968) and Italv 
(1969). 

Ross received the Joseph Marie Jacquard Award from 
the Numerical Control Society in 1975. The paper •Theo- 
retical f oundations for the Computer-Aided Design Svs- 
lem coauthored w ith J.E. Rodriguez, then senior vice pres- 

l \rn»e l e SOllCCh ‘ . rucci ' tfd thc Prize Paper Award at the 
ai-ii i, Spring Joint Computer Conference in 1965. The 
paper “A ED Approach to Generalized Computer-Aided 
Design shared the Prize Paper Award at the ACM 20th 
Anniversary National Meeting in August 1967. In 1980 Ross 
received the Distinguished Service Award from the Society 
lot Manufacturing Engineers. 

Martin Grcenberger.* Grecnhcrger was horn in Elizabeth. 

■ Wl - Hc reived BA. MA. and PhD degrees in 

applied mathematics from Harvard University. Before join- 
uig the Ml T faculty in 195s. Grecnhcrger was manager of 
Applied Science Cambridge, the IBM group that eooper- 
\ nT ' Ml r .‘ n lhc cslablish ment and operation of the 
• T ( oinputanon Center. Grcenberger is the coauthor of 
the I /6_ book. Mnrotma/ysis <>f Socioeconomic Svsians — 

.1 .S inuiltiiimi Study. 


John McCarthy. Born in Boston on Sep- 
tember 4. 1927. John McCarthy holds a BS 
in mathematics from CalTech ( 1 948) and a 
PhD in mathematics from Princeton 
(1951 ). At Princeton he was the first Proc- 
tor lellow and later Higgins research in- 
structor in mathematics. He has also been 
associated with the faculty of Dartmouth 
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College and MIT, and is now Charles M. Pigott professor of 



computer science and director of the Artificial Intelligence 
Laboratory at Stanford University. 

McCarthy participated in the development of Al*ol 58 
;'" d . Als “' f d creaKd Liup program™, ' „» swtem 
1 I, lie at MIT. where, with Marvin Minsky, he organized and 
directed the Artificial Intelligence Projecl. In th'e same lime 
period he was a significant instigator of the work on time- 
sharing at MIT. 

He was chosen as the 1071 ACM Turing Award recipient 
and awarded the 1988 Kyoto Prize for outstanding aceom- 
pnsliments in advanced technology. 


J.A.N. Lee (editor). "JAN" has been ac- 
tive in computer-related studies since the 
mid-1950s and has served as the director 
ol computing and head of department of 
three major North American universi- 
^ tios - ,1ils spent the past four years on 

■4 leave ,rom his position at Virginia Polv- 
technic Institute and State University 
serv.no as the director of the Institute for Information Tech- 
no'ogy of the Virginia Center for Innovative Technology 
His principal research interests have been in the design and 
implementation of compilers, testing techniques and [he 
hislory ot comparing. Lee serves as the editor-in-chief of the 
of the History of Computing a nd is a past vice 
president ol ACM. V 
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t Robert F. Rosin (interviewer). Rosin 
earned a BS in economics, politics, and 
engineering at MIT (1957) and MS and 
PhD degrees in communication sciences 
at the University of Michigan (I960 and 
1964). He taught computer science at the 
university level until 1976 and has since 
. , worked in the computer-telecommunica- 

lions industry. He is currently vice president and principal 
architect of Enhanced Service Providers. Inc., a start-up 
companythal tsdeveloping software to integrate voice, text, 
and image mformanon. He also provides consulting services 
in the areas of communication and information swtem at- 
chitecture and education. 

Rosin is a founding editor or the Annals, and he served 
on the program committee for the first ACM SIGPLAN 

s 'S 0r! ,™ P ? 8ramraing Lan ? ua S es (HOPL) Conference 
held in 1978. He will repeat that role for the second confer- 
ence (HOPL-II). planned for 1993. 


I- • IEEE Annuls of the History of Computing. V«|. 14, No. I. 1992 


<6a A 


Time-Sharing at MIT 

introduction 

J.A.N. LEE 


T ime-sharing as an operating systems implementation 
methodology is. in many minds, synonymous with MIT 
i the names of Fernando Corbato and Robert Fano. Even 
. ugh the technique existed and was implemented in pre- 
<v6«) special-purpose systems, numerous other implementa- 
tions arose in the late 1960s in conjunction with interactive 
computing, so it is almost inconceivable today for a vendor 
to deliver a mainframe computer system without some mea- 
sure of time-sharing and interaction. CTSS and Project 
MAC are clearly identifiable pioneer efforts. In 1988. the 
Laboratory for Computer Science at MIT invited partici- 
pants to a two-day symposium to celebrate the 25th anniver- 
of the laboratory. That celebration — the MIT Com- 
. or Science Research Symposium, held October 26 and 
17 at MIT’s Kresge Auditorium — took the .form of an 
exemplary set of presentations on the future of computer 
science. 

The activities of the laboratory in 25 years, since its 
inception as Project MAC by Robert Fano. have covered a 
wide variety of topics far broader than just time-sharing and 
interactive computing: 

• Computer-aided design 
• Time-sharing 
* Mathlab and Macsyma 
• Artificial intelligence 

• The development of editors (TECO. Runoff. Script) 
• Lisp 
• Theory 
• Labware 
• Parallel Computing 
• Education 

• The emergence of companies — Prime Computer. 

SofTech. Thinking Machines, and many others 
* Abstraction and specification 

Building on the good fortune of having several partici- 
pants in the early development of CTSS and Project MAC 
present in Cambridge, the Annuls sought the cooperation of 
the laboratory through the good offices of Michael 
Dertouzos and Albert Meyer to record interviews with the 
attending pioneers. These interviews were transcribed by 
Kellie Ross ot the Virginia Center for Innovative Technol- 
-)'■ and edited by Robert F. Rosin and J.A.N. Lee. Each 
• ,: i‘.'.pant was also afforded the opportunity to edit his 
presentation, comment on the statements of others, and 
provide footnotes of further explanation. False starts, blind 
ends, and unfocused asides have been deleted from the 
transcript, and some minor reordering of the proceedings 


has been undertaken by the editore. The original audiotapes 
are in the possession of the MIT archives. Copies of these tapes 
and the original transcript, unedited (but one-pass corrected 
for accuracy), have been deposited with the Charles Babbage 
Institute of the University of Minnesota. Minneapolis. 

The interviews pointed to numerous supportive articles and 
reports that have documented the technological history of the 
development of both CTSS and Project MAC, as well as the 
subsequent design of the Multics system. We have attempted 
in this special issue of the Annals to supplement the interviews, 
which concentrated on the more human and administrative 
side of the history, by reprinting (and publishing for the first 
time in many cases) excerpts from the relevant documents, 
together with our commentary, which we hope will provide the 
bridges in time and activity'. Unfortunately, during the devel- 
opment of this special issue, one of our pioneers died — Joseph 
C.R. (Lick) Licklider. We dedicate this special issue to his 
memory'. We only met him briefly, but it was clear that the 
participants regarded him with great love and admiration for 
his contributions and support. 

Definition 

Like terms such as "compiler ” and "operating system." the 
term "time-sharing" has been applied to a set of developments 
over a period of 30 years, differing in 1985 from an early 
application of the term in 1955. Initially the term was applied 2 
to a mechanism by which the processing power of the central 
computer was shared between a number of different activities 
of differing speeds, especially activities related to the operation 
of resources such as input-output devices. By this means, the 
processing time of a central processor that would be wasted in 
waiting for a slower device to complete its task is assigned to 
another task that is ready to execute. This technique was used 
in the SAGE system to implement the air defense system and 
later the SABRE airline reservation system. With the develop- 
ment of the CTSS system by Corbato and others at MIT, and 
subsequent extension to Multics through Project MAC, the 
technique for the implementation of an interactive multitermi- 
nal system became synonymous with “interactive computing.’’ 

Thus time-sharing is a methodology for scheduling a 
computer so several users can interact with it simultaneously 
and without apparent interference from each other. Al- 
though time-sharing was initially perceived by many as a 
programming convenience for debugging, 33 the perception 
soon was extended to include the provisions of a wide 
variety of on-line services and the availability of a large 
central memory shared among the user community. In the 
strict sense of the terms, it is clear that “interactive comput- 


I H5K-4« I Mn/VZ/n KKMHH 3S03.IMI <9 IW2 IEEE 


IEEE Annals of the History of Computing, Vol. 14, No. 1. 1992 • 13 



Time lines for time-sharing, CTSS. and Project MAC.* 

insT was one goal of Project MAC and "time-sharing" was 
one way to implement that goal. Indeed, in those days using 
a •'ingle large computer was the only economical way. 

Shortly, with Project MAC and projects elsewhere, those 
two terms became confused, and "time-sharing" came to 
include interactive computing" for many people. Later, of 
course, "interactive computing" was also achieved through 
personal computers. As personal computers have been used 
as the remote, intelligent terminals for mainframe systems, 
the terminology has become even more confusing. Here we 
generally use the term "time-sharing" to apply to that style 
ol computer usage which uses the technology to implement 
interactive computing. In the next article, we briefly trace 
the claims to the early uses of the term time-sharing and the 
ditferent meanings implied by each user. 

Closed shop versus open shop 

In the mid-1950s relatively reliable commercial comput- 
ers were becoming available and high-level languages were 
moving the task of programming from the hands of the 
professional programmer to the problem poser, a move 
which was accompanied by the concurrent need for more 
accessible computer systems. Meanwhile, systems were be- 
coming smarter, and professional programmers were avail- 
able to construct ever larger programs. Computing center 
staffs were being pressured to make more efficient use of 
th e still expensiv e equipment. 

* Adapted from the time line for the Project MAC 25th anniver- 
sary by Peter Elias. 


One solution to this problem was the emergence of 
monitors, supervisory systems, and. eventually, operating 
systems. - Under this scenario, programs and data for a 
collection of jobs were prerecorded (often off-line.) on mag- 
netic tape. Then, under the supervision of a monitor pro- 
gram. the jobs would run sequentially without operator or 
programmer interaction until they terminated or. as was 
often the case, encountered an er'ror condition. This pro- 
cessing mode was really a means of improving the effective- 
ness of a closed-shop operation. Although it also cut down 
on the idle or wait time of the processor, it did little to 
improve the ability of users to debug their programs. The 
turnaround time for a closed-shop operation was reduced 
very little for the users, and the problem was aggravated as 
larger and more ambitious programs were attempted. 

Cons ersely. in an open-shop operation, where users op- 
erated the computer themselves in a manner we would now 
refer to as '•personal computing" and very definitely in an 
"interactive" mode, the ratio of available clock cvcles to 
utilized cycles was extremely high. The percentage'of wait 
time for user actions to useful operation often exceeded 80 
to 90 percent during debugging activities. Open-shop users 
did not want to give up their "personal, interactive comput- 
ing," and the administrators of closed-shop systems were 
unwilling to give up the advantages of machine efficiency 
gained through the use of operating systems. 

One other element that contributed to the attractiveness 
ol time-shared, interactive terminal systems was the inter- 
facing of computers with communication systems — espe- 
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dally through the public telephone system. As early as 1940 
at a mathematics conference at Dartmouth College, the 
Stibitz relay computer at the Bell Telephone Laboratories 
was operated remotely by a single user a few hundred miles 
awav. :9 Communications were obviously essential to the 
*“’• elopment of the massive SAGE system, which involved 
• eral remote control sites with multiple users, each at a 
specially designed terminal interacting independently with 
information displayed on cathode-ray tubes. Similarly, the 
IBM and American Airlines development of the SABRE 
system involved communications with hundreds of termi- 
nals distributed geographically. 

These mid-1950s systems provided special-purpose ser- 
vices to the users through a single software system where 
the terminals were used for data entry and output rather 
r.an for program development, debugging, and execution, 
-v hat was different in John McCarthy's 1959 proposal 33 (an 
influential but unpublished internal memorandum to Philip 
Morse, director of the MIT Computation Center) was the 
vision of a computer used independently by different per- 
sons for entirely different programs. Perhaps the major step 
that McCarthy suggested was to optimize the use of human 
time rather than computer time. The optimal use of com- 
puter time was to be transparent to the user. 

Technology 

While the feasibility of the basic concepts of time-shar- 
>ng. communications, and interaction had been verified in 


individual projects, two technology improvements provided 
the key steps toward practicality. These were the replace- 
ment of the vacuum tube by the transistor and the availabil- 
ity of large-capacity memories. Transistors provided the 
reliability of systems that were to be inserted into an envi- 
ronment which was tantamount to a public utility. Large- 
scale memories provided a medium for the storage and rapid 
retrieval of the large variety of software packages used by 
individual users, as well as their personal programs and data. 
The timing was just right! McCarthy 33 proposed the key 
hardware modifications to an IBM 709 computer that would 
allow time-shared debugging by multiple users. Corbato 
said that "it was McCarthy's early advocacy of time-sharing 
which inspired much of the interest in developing such 
systems." 


I n the history of time-sharing and interactive comput- 
ing at MIT, two major events followed the early 
developments of the 1950s: The demonstration of the 
Compatible Time-Sharing System (CTSS) in 1961 and 
its extension into the Multics system within Project 
MAC. These occurred against the backdrop of plan- 
ning and design politics, interactions with computer 
vendors to supply the needed hardware features, and 
attempts to maintain the viability of the ongoing ser- 
vices of the Computation Center. E3 
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Claims to the Term “Time-Sharing” 

J.A.N. LEE 


time-share - v -To interleave the use of a device for two or more purposes. 

time-shared system - n - A specific system in which available central-com- 
puter time is shared among several jobs as directed by a scheduling plan or 
formula. 

time-sharing - adj - 1. The apportionment of intervals of time availability of 
various items of equipment to complete the performance of several tasks by 
interlacing. (Contrasted with multiprogramming.) 2. The use of a device for 
two or more purposes during the same overall time interval, accomplished by 
interspersing the computer component actions in time. 

Charles J. Sippl, Computer Dictionary and Handbook, 
Howard W. Sams. New York, 1965 


T he emergence of a term is not always coincidental with 
the initial development of that particular technology or 
system. Even in the case of computers, the word initially 
used was "calculator." The word "computer" was originally 
applied either to humans who did computations using me- 
chanical calculators'" or to the computational element of a 
bomb aiming device.* In 1966FanoandCorbato 21 published 
a paper in Scientific American which attributed the origin of 
time-sharing to Christopher Strachey in a 1960 paper 43 pre- 
sented originally at the 1959 UNESCO conference. This 
resulted in a letter to the editor from Robert Berner 6 in 
which he claimed that his article in the 1957 issue of Auto- 
matic Control 4 was the original reference to time-sharing. 
Berner also pointed out that it was reported in the Journal 
of the Franklin Institute that he had used the word in a 
presentation in the same year. In turn. Robert Dodds wrote 
to Berner quoting a 1949 letter in which he described his 
(unnamed) invention: 

A system consisting of the following: one or more 
input-output devices.. .each conveying its information 
to a common location distant from one or all of the 
input-output devices; one or more devices which gen- 
erate the electrical impulses that convey information 
and that control the various operations of the several 
devices; one or more scanning or gating devices to 

London Times. July ,S, I *>44. 
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segregate the information originating from the sev- 
eral input-output devices... 18 

This description appears to accentuate the confusion 
between the process of "time-sharing" that Berner de- 
scribed and "interactive computing" that was prevalent in 
1966. At the time of Berner's Franklin Institute lecture, 
time-sharing was already being implemented as part of the 
SAGE system. 2 and shortly thereafter IBM and American 
Airlines developed the SABRE system for on-line passen- 
ger scheduling and ticketing. When Strachey 43 used the 
word in 1959. adding the concept of on-line, he added also 
debugging for programmers. Donald Knuth wrote to 
Strachey 25 years later: 

John McCarthy thinks he invented [time-sharing]. So 
does K.D. Tocher. I [have] read that Lord Halsburv 
says. ..that the idea of time-sharing was "very much in 
the air." I hope you'll have time to write me a letter 
explaining the history of time-sharing as you see it... 

Strachey responded: 

The paper I wrote called "Time-sharing in Large Fast 
Computers” was read at the first (pre IFIP) confer- 
ence at Paris in 1960 [sic]. It was mainly about multi- 
programming (to avoid waiting for peripherals) al- 
though it did envisage this going on at the same time 
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as a programmer was debugging his program at a 
console. I did not envisage the sort of console system 
•.vhich is now so confusingly called time-sharing. I still 
think my use of the term is the more natural. 

Campbell- Kelly 4 also quoted Strachey as saying: 

“Time-sharing in Large Fast Computers" was proba- 
bly the first paper to discuss time-sharing and multi- 
programming as we know them. It is a matter of 
history that the time-sharing idea became extremely 
fashionable in the middle sixties and dominated much 
of the work on computing at the time. When I wrote 
the paper in 1959. 1, in common with everyone else, 
had no idea of the difficulties which would arise in 
writing the software to control either the time-sharing 
or multi-programming. If I had. I should not have 
been so enthusiastic about them. 

Strachev filed an application for a patent on time-sharing 
in 1959. which was eventually granted (British patent 
924672) in 1965. Campbell-Kellv suggests that “the idea of 
tieractive time-sharing is plainly there in embryo." In the 
>i.me year ( 1959). John McCarthy wrote a memo to Philip 
Morse* suggesting modifications to the IBM 709. which was 

* The date on the memorandum is January 1 . 1959: there has been 
a suggestion that the McCarthy memorandum was actually written 
in 1960. the misdating being a common error in the early days of a 
new year. See the next section for the content of the memorandum 
and McCarthy’s comments on this suggestion. 


being contributed by IBM to the Computation Center, in 
order to develop "a time-shared operator program.” 

In 1962 McCarthy suggested that the concept, if not the 
term, goes even further back: “The subject was also touched 
on in the lectures by Kemeny and Perlis. In 1945 Vannevar 
Bush 8 discussed a system for personal information retrieval 
called Memex. which probably requires a computer system 
of the kind that I am going to discuss for its realization." 


I t is apparent that there have been two major uses of the 
term corresponding to two major periods of the history, 
with two different spellings (with or without the hyphen): 

• Before 1960, time sharing described a method of 
implementing multiprogramming (Astrahan and Ja- 
cobs. 2 Berner, 4 ' 6 Dodds. ls and Strachey 43 ). 

• After 1960. time-sharing described a technique 
by which interactive computing was developed 
(McCarthy 33 and Fano and Corbato 21 - 22 ). 0 
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T wo key elements were necessary to implement time- 
shared. interactive computing: interfaces with commu- 
nications facilities, and a machine design that supported 
interrupts, memory protection, and a large fast-access exter- 
nal store. Each of these elements was feasible in 1959. as 
demonstrated by George R. Stibitz in 1940 and by the SAGE 
development in 1957. 

The lirst public demonstration of remote operation of a 
digital computer and ol computer-telephone communica- 
tions was conducted as part of the 1940 annual meetina of 
the Mathematical Association of America. Problems were 
entered into a teletypewriter located in McNutt Hall on the 
Dartmouth campus in Hanover. N.H. They were then trans- 
mitted via standard Bell System telecommunications facili- 
ties to the Bell Telephone Laboratories in New York Citv. 
where they were solved on-line by the BTL Model 1 Com- 
plex Number Calculator. The results were immediatelv re- 
turned on-line via the same telecommunications link to the 
teletypewriter located on the Dartmouth campus. 250 miles 
away. 

Stibitz. who was behind both the demonstration and the 
digital computer used in it. was then a mathematician on the 
technical staff of the Beil Telephone Laboratories. (Now he 
is prolessor emeritus of physiology at the Dartmouth Med- 
ical School.) 

Stibitz describes the ability to do remote computing as a 
natural and integral part of the design of his system. It was 
natural and "no big thing" to demonstrate this device at 
Dartmouth by leaving the computer where it was and oper- 
ating it remotely via a teletypewriter link, rather than goina 
to all the trouble and expense of moving the machine itself 
Irom New York to Hanover. After all. teletypewriters in 
other departments in BTL had already tapped into the 
system on occasion to get their computations done. The 
length of the teletype line, whether it was 25 feet or 250 
miles, involved no major change in operational techniques 
or concept.-' 

In their 1957 paper. "SAGE — A Data Processing Sys- 
tem for Air Defense" (Proc. EICC © 1957 IRE (now 
IEEE)). R.R. Everett. C.A. Zraket.and H.D. Bennington-' 
described the working of the SAGE system and not only 
used the term "time-sharing" but also provided their ow-n 
description: 

The central computer performs air-defense pro- 
cessing in the following manner (see figure l [repro- 


duced on the facing page]). The buffer storage tables, 
the system-status data, and the system computer pro- 
gram are organized in hundreds of blocks — each 
block containing from 25 to 4000 computer words. A 
short sequence-control program in the central 
computer's core memory transfers appropriate pro- 
gram and data blocks into core memory, initiates 
processing, and then returns appropriate table blocks 
(but never programs) back to the drum. To take 
advantage ot the in-out break feature, operation of 
each air-defense routine is closely coordinated with 
operation of the sequence-control program so that 
programs and data are transferred during data pro- 
cessing. 

By timesharing [emphasis added] the central com- 
puter. each of the air-defense routines is operated at 
least once every minute — many are operated every 
several seconds. One interesting feature is that the 
frequency of program operation is locked with real 
time rather than allowed to vary as a function of load: 
during light load conditions the sequence-control pro- 
gram will often "mark time" until the real-time clock 
indicates that the next operation should be repeated. 
Such synchronization with real time simplifies manv 
of the control and input-output functions without 
causing any degradation in system performance. 

Both of these demonstrations showed the feasibility of 
the concept, but it took an environment (at MIT) and a 
brilliant mind (John McCarthy) to put two and two together 
into a far-reaching system. 

Digital computation* began at MIT in 1947 with the 
Whirlwind I computer. Whirlwind was four or five times 
faster than its predecessors by virtue of its excellent elec- 
tronic design and parallel operation. By 1 953, core memory, 
developed by Jay Forrester and his associates at MIT. 
yielded another factor of two. The standards of speed and 
reliability set at that time have now come to be expected of 
modern computing equipment. 

While Whirlwind satisfied the needs of many MIT users, 
the pressures of special requirements led to the acquisition 
of other computers as well. In 1955 the Instrumentation 


* Of course in the field of analog computation. Vannevar Bush 
had led the world with the development of the Differential An- 
alyzer. 
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•;;ssrc 1. Dynamic program operation.^’ Reproduced with permission (© 1957 IRE (now IEEE)). 


Laboratory obtained an IBM 650 computer, and in 1956 the 
Naval Supersonic Laboratory installed a Bendix G15 com- 
puter for processing wind tunnel data. 

In 1956. IBM provided an IBM 704 to be located at MIT 
with one shift per day for the use. without charge, of educa- 
tional and research projects at MIT. and a similar amount 
of time for the use of universities and colleges in the New 

•viand area. The Computation Center, under the direc- 
• ;n of Philip M. Morse, was formed for the administration 
and efficient use of this facility. Subsequently, the TX-0 
computer was loaned to the Electrical Engineering Depart- 
ment by Lincoln Laboratory. 

The need for computer capacity at MIT continually in- 
creased. In 1960 the Computation Center IBM 704 was 
replaced by the more powerful IBM 709 computer, and 
several smaller computers also were installed by various 
MIT groups. Even more ambitious expansion was sched- 
'•v'l for the immediate future. 

Reminiscences on the History of 
Time-Sharing 

John McCarthy 

At the time of our inteniews with the CTSS and Project 
I AC pioneers, we invited John McCarthy to join the group 
.■■:ch provided this record following the 25th anniversary 
‘■-■chrutions of the founding of the Laboratory of Computer 
Science. McCarthy was unable to extend his stay in the Cam- 


bridge area but graciously wrote his own memories of this 
era. 

I remember thinking about time-sharing at the time of 
my first contact with computers and being surprised that this 
was not the goal of IBM and all the other manufacturers and 
users of computers. This might have been around 1955. 

By time-sharing, I meant an operating system that per- 
mits each user of a computer to behave as though he were 
in sole control of a computer, not necessarily identical with 
the machine on which the operating system is running. 
Christopher Strachey may well have been correct in saying 
in his letter to Donald Knuth* that the term was already in 
use for time-sharing among programs written to run to- 
gether. This idea had already been used in the SAGE sys- 
tem. I do not know how this kind of time-sharing was 
implemented in SAGE. Did each program have to be sure 
to return to an input polling program or were there inter- 
rupts? Who invented interrupts anyway?** I thought of 
them, but I do not believe I mentioned the idea to anyone 
before I heard of them from other sources. 

My first attempts to do something about time-sharing 
were in the fall of 1957 when I came to the MIT Computa- 
tion Center on a Sloan Foundation fellowship from Dart- 
mouth College. It was immediately clear to me that time- 
sharing the IBM 704 would require some kind of interrupt 
system. I was very shy of proposing hardware modifications, 

* See Strachey’s response to Knuth in the previous section. 

** Alan ScherT reported that the patents on interrupt-driven I/O 
are held by three IBM researchers. 
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Time-Sharing at MIT 


John McCarthy’s 1959 memorandum 


To: Professor P.M. Morse 

From: John McCarthy 

Subject: A Time-sharing Operator 
Program for our 
Projected IBM 709 
Date: January 1, 1959 

Introduction 

This memorandum is based on 
the assumption that MIT will be 
given a transistorized IBM 709 
about July 1960. 1 want to propose 
an operating system for it that will 
substantially reduce the time re- 
quired to get a problem solved on 
the machine. Any guess as to how 
much of a reduction would be 
achieved is just a guess, but a fac- 
tor of five seems conservative. A 
smaller factor of improvement in 
the amount of machine time used 
would also be achieved. 

The proposal requires a com- 
plete^ revision in the way the 

The format of the original memo was 
changed for reproduction here. 


machine is used, will require a long 
period of preparation, the develop- 
ment of some new equipment, and a 
great deal of cooperation and even 
collaboration from IBM. Therefore, if 
the proposal is to be considered seri- 
ously, it should be considered 
immediately. I think the proposal 
points to the way all computers will 
be operated in the future, and we 
have a chance to pioneer a big step 
forward in the way computers are 
used. The ideas expressed in the fol- 
lowing sections are not especially 
new, but they have formerly been 
considered impractical with the com- 
puters previously available. They are 
not easy for computer designers to 
develop independently since they in- 
volve programming system design 
much more than machine design. 

A quick service computer 

Computers were originally devel- 
oped with the idea that programs 
would be written to solve general 


classes of problems and that after 
an initial period most of the com- 
puter time would be spent in 
running these standard programs 
with new sets of data. This view 
completely underestimated the vari- 
ety of uses to which computers 
would be put. The actual situation is 
much closer to the opposite extreme, 
wherein each user of the machine 
has to write his own program and 
that once this program is debugged, 
one run solves the problem. This 
means that the time required to solve 
the problem consists mainly of time 
required to debug the program. This 
time is substantially reduced by the 
use of better programming lan- 
guages such as Fortran. Lisp (the 
language the Artificial Intelligence 
Group is developing for symbolic ma- 
nipulations) and COMIT (Yngve's 
language). However, a further large 
reduction can be achieved by reduc- 
ing the response time of the 
computation center. 


especially as I did not understand electronics well enough to 
read the logic diagrams. Therefore. I proposed the minimal 
hardware niodilication I could think of. This involved in- 
stalling a relay so that the 704 could he put into trapping 
mode hv an external signal. It was also proposed to connect 
the sense switches on the console in parallel with relavs that 
could he operated bv a Flexowriter. 

When the machine went into trapping mode, an interrupt 
to a fixed location would occur the next time the machine 
attempted to execute a jump instruction (then called a trans- 
fer). The interrupt would occur when the Flexowriter had 
set up a character in a relay buffer. The interrupt program 
would then read the character from the sense switches into 
a buffer, test whether the buffer was full, and if not return 
to the interrupted program. If the buffer was full, the pro- 
gram would store the current program on the drum and read 
in a program to deal with the buffer. 

It was agreed (I think I talked to Dean Arden only) to 
install the equipment, and I believe that permission was 
obtained Irom IBM to modify the computer. The connector 
to be installed in the computer was obtained. 

However, at this time we heard about the "real-time 
package” for the IBM 704. This RPO (Request for Price 
Quotation was IBM jargon for a modification to the com- 
puter whose price was not guaranteed), which rented for 
$2,500 per month, had been developed at the request of 
Boeing for the purpose of allowing the "04 to accept infor- 
mation from a wind tunnel. Some element of ordinary time- 


sharing would have been involved, but we did not seek 
contact with Boeing. Anyway, it was agreed that the real- 
time package, which involved the possibility of interrupting 
after any instruction, would be much better than merely 
putting the machine in trapping mode. Therefore, we under- 
took to beg IBM for the real-time package. IBM's initial 
reaction was favorable, but nevertheless it took a long time 
to get the real-time package — perhaps a year, perhaps two. 

It was then agreed that someone, perhaps Arnold 
Siegel.® would design the hardware to connect one 
Flexowriter to the computer, and later an installation with 
three would be designed. Siegel designed and built the 
equipment, the operating system was suitably modified (I 
do not remember by whom), and a demonstration of on-line 
Lisp was held fora meeting of the MIT Industrial Affiliates. 
This demonstration, which I planned and carried out. had 
the audience in a fourth-floor lecture room and me in the 
computer room and a rented closed-circuit TV system. Steve 
Russell, who worked for me. organized the practical details, 
including a rehearsal. This demonstration was called time- 
stealing. and was regarded as a mere prelude to proper 
lime-sharing. It involved a fixed program in the bottom of 
memory that collected characters from the Flexowriter in a 
butler while an ordinary batch job was running. It was only 
after each job was run that a job that would deal with the 

* Siegel had engineered a Flexowriter input device on Whirlwind 
for Doug Ross’ Data Reduction Project in |V5 p. 
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The response time of the MIT 
Computation Center to a perfor- 
mance request presently varies 
from 3 hours to 36 hours depending 
on the state of the machine, the effi- 
ciency of the operator, and the 
backlog of work. We propose by 
time-sharing, to reduce this re- 
sponse time to the order of 1 
second for certain purposes. Let us 
first consider how the proposed sys- 
tem looks to the user before we 
consider how it is to be achieved. 

Suppose the average program 
to be debugged consists of 500 in- 
structions plus standard 
subroutines and that the time re- 
quired under the present system for 
an average debugging run is 3 min- 
utes. This is time enough to 
execute 7,000.000 704 instructions 
or to execute each instruction in the 
program 14.000 times. 

Most of the errors in programs 
could be found by single-stepping 
or multiple-stepping the program as 
used to be done. If the program is 
debugged in this way, the program 


will usually execute each instruc- 
tion not more than 10 times, 1/1400 
as many executions as at present. 
Of course, because of slow human 
reactions the old system was even 
more wasteful of computer time 
than the present one. Where, how- 
ever, does all the computer time 
go? 

At present most of the computer 
time is spent in conversion (SAP-bi- 
nary, decimal-binary, 
binary-decimal, binary-octal) and in 
writing tape and reading tape and 
cards. 

Why is so much time spent in 
conversion and input output? 

1 . Every trial run requires a fresh 
set of conversions. 

2. Because of the slow response 
time of the system it is necessary to 
take large dumps for fear of not 
being able to find the error. The 
large dumps are mainly unread, but 
nevertheless, they are necessary. 
To see why this is so, consider the 
behavior of a programmer reading 


his dump. He looks at where the 
program stopped. Then he looks at 
the registers containing the partial 
results so far computed. This sug- 
gests looking at a certain point in 
the program. The programmer may 
find his mistake after looking at not 
more than 20 registers out of say 
1000 dumped, but to have pre- 
dicted which 20 would have been 
impossible in advance and to have 
reduced the 1 000 substantially 
would have required cleverness as 
subject to error as his program. The 
programmer could have taken a run 
to get the first register looked at, 
then another run for the second, 
etc., but this would have required 
60 hours at least of elapsed time to 
find the bug according to our as- 
sumptions and a large amount of 
computer time for repeated loading 
and re-runnings. The response time 
of the sheet paper containing the 
dump for any register is only a few 
seconds, which is OK except that 
one dump does not usually contain 
(continued on the following page) 


characters typed in would be read in from the drum. This 
Sob would do what it could until more input was wanted and 
•uld then let the operating system go back to the batch 
.•am. This worked for the demonstration, because at cer- 
. :i:! hours the MIT Computation Center operated a batch 
stream with a time limit of one minute on any job. 

Around the time of this demonstration. Herbert Teager 
came to MIT as an assistant professor of electrical engineer- 
ing and expressed interest in the time-sharing project. Some 
of the ideas of time-sharing overlapped some ideas he had 
while on his previous job. but I do not remember what they 
were. Philip Morse, the director of the Computation Center. 
,s ked me if I was agreeable to turning over the time-sharing 
’ • ject to Teager. since artificial intelligence was my main 
merest. 1 agreed to this, and Teager undertook to design 
the three-Flexowriter system. I'm not sure it was ever com- 
pleted. There was a proposal for support for lime-sharing 
submitted to the National Science Foundation, and money 
was obtained. I do not remember whether this preceded 
Teager. and I do not remember what part I had in preparing 
it or whether he did it after he came. This should be an 
important document, because it contains that year’s concep- 
’ of and rationale for time-sharing.* 

Besides that. IB VI was persuaded to make substantial 
modifications to the IBM 709 to be installed at the MIT 


Regrettably, we have been unable to locate this proposal, but a 
later report on the work is included in this issue. 


Computation Center. These included memory protection 
and relocation, and an additional 32.768 words of memory 
for the time-sharing system. Teager was the main specifier 
of these modifications. I remember my surprise when IBM 
agreed to his proposals. I had supposed that relocation and 
memory protection would greatly slow the addressing of the 
computer, but this turned out not to be the case. 

Teager s plans for time-sharing were ambitious and, it 
seemed to many of us. vague. Therefore. Fernando Corbatd 
undertook an "interim" solution using some of the support 
that had been obtained from NSF for time-sharing work. 
This system was demonstrated some time in 1961 , but it was 
not put into regular operation. That was not really possible 
until the ARP A support for Project MAC permitted buying 
a separate IBM 7090. 

Around 1960 I began to consult at BBN on artificial 
intelligence and explained my ideas about time-sharing to 
Ed Fredkin and J.C.R. Licklider. Fredkin, to my surprise, 
proposed that time-sharing was feasible on the PDP-1 com- 
puter. This was DEC'S first computer, and BBN had the 
prototype. Fredkin designed the architecture of an interrupt 
system and designed a control system for the drum to permit 
it to be used in a very efficient swapping mode. He con- 
vinced Ben Gurley, the chief engineer for DEC, to build this 
equipment. It was planned to ask NIH (National Institutes 
for Health) for support, because of potential medical appli- 
cations of time-sharing computers, but before the proposal 
could even be written. Fredkin left BBN. I took technical 
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information enough to get the entire 
program correct. 

Suppose that the programmer 
has a keyboard at the computer 
and is equipped with a substantial 
improvement on the TX-0 interroga- 
tion and intervention program 
(UT3). (The improvements are in 
the direction of expressing input 
and output in a good programming 
language). Then he can try his pro- 
gram. interrogate individual pieces 
of data or program to find an error, 
make a change in the source lan- 
guage and try again. 

If he can write the program in 
source language directly into the 
computer and have it checked as 
he writes it, he can save additional 
time. The ability to check out a pro- 
gram immediately after writing it 
saves still more time by using the 
fresh memory of the programmer. I 
think a factor of 5 can be gained in 
the speed of getting programs writ- 
ten and working over present 
practice, if the above mentioned fa- 
cilities are provided. There is 


another way of using these facilities 
which was discussed by S. Ulam a 
couple of years ago. This is to use 
the computer for trial and error pro- 
cedures where the error correction 
is performed by a human adjusting 
the parameters. 

The only way quick response 
can be provided at a bearable cost 
is by time-sharing. That is, the com- 
puter must attend to other 
customers while one customer is re- 
acting to some output. 

The problem of a time-sharing 
operation system 

I have not seen any comprehen- 
sive written treatment of the 
time-sharing problem and have not 
discussed the problem. This treat- 
ment is certainly incomplete and is 
somewhat off-the-cuff. The equip- 
ment required for time-sharing is 
the following. 

a. Interrogation and display de- 
vices (Flexowriters are 


charge of the project as a one-day-a-week consultant, and 
Sheldon Boilen was hired to do the programming. I rede- 
signed the memory extension system proposed by DEC and 
persuaded them to build the modified system instead of the 
two systems they were offering, but fortunately had not 
built. I also supervised Boilen. 

Shortly after this project was undertaken. DEC decided to 
give a PDP-l to the MIT Electrical Engineering Department. 
Under the leadership of Jack Dennis.* this computer was 
installed in the same room as the TX-0 experimental transis- 
torized computer that had been retired from Lincoln Labora- 
tory when the TX-2 was built. Dennis and his students under- 
took to make a time-sharing system for it. The equipment was 
similar, but they were given less memory than the BBN project 
had. There was not much collaboration. 

My recollection is that the BBN project was finished first 
in the summer of 1962. but perhaps Corbato remembers 
earlier demonstrations of CTSS.** I left for Stanford in the 
fall of 1962. I had not seen CTSS. and I believe I had not 
seen Dennis’ system operate either. BBN did not operate 
the lirst system and did not even fix the bugs. They had few 
computer users and were content to continue the system 
whereby users signed up for the whole computer. They did 


* Earl Pugh of the Electrical Systems Laboratory, which was given 
the responsibility for the PDP-l. did the original installation and 
operation of the PDP-l. (Note added by Doug Ross during review, j 
** See Time Line. pp. 14-15. 


possible but there may be 
something better and 
cheaper); 

b. An interrupt feature on the 

computer; we’ll have it; • 

c. An exchange to mediate be- 
tween the computer and the 
external devices. This is the most 
substantial engineering problem, 
but IBM may have solved it. 

In general the equipment re- i 

quired for time-sharing is well 
understood, is being developed for 
various advanced computers, e.g., 

Stretch, TX-0, Metrovich 1010, 

Edsac 3. 1 would not be surprised if 
almost all of it is available with the 
transistorized IBM 709. However, 
the time-sharing has been worked 
out mainly in connection with real- a 

time devices. The programs 
sharing the computer during any 
run are assumed to occupy pre- 
scribed areas of storage, debugged 
already, and to have been written 
together as a system. We shall 
have to deal with a continuously 


undertake a much larger follow-on project involving a time- i 
shared PDP-l that was installed in Massachusetts General | 
Hospital, where it was not a success. The computer was I 
inadequate, there were hardware and software bugs, and 
there was a lack of application programs — but mainly the 
project was premature. 

At the same time that CTSS. the BBN system, and the 
Electrical Engineering Department systems were being de- 
veloped. MIT had started to plan for a next-generation 
computer system. The management of MIT evidently 
started this as an ordinary university planning exercise and 
appointed a high-level committee consisting of Philip 
Morse. Albert Hill, and Robert Fano to supervise the effort. 
However, the actual computer scientists were persuaded 
that a revolution in the way computers were used was called 
for. The lower level committee was chaired by Teager, but 
after his ideas clashed with those of everyone else, the 
committee was reconstituted with me as chairman. The 
disagreement centered around how ambitious to be and 
whether to go for an interim solution. Teager wanted to be 
very ambitious, but the rest of us thought his ideas were 
vague. He wanted MIT to acquire an IBM 7030 (Stretch) 
computer as an interim solution. As it turned out, acquiring 
a Stretch would have been a good idea. 

Our second report to MIT proposed that MIT send out 
a request for proposals to computer manufacturers. On the 
basis of the responses, we would then ask the government 
for the money. The RFP was written, but MIT stalled. 
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changing population of programs, 
most of which are erroneous. 

The major problems connected 
with time-sharing during program 
development seem to be as follows: 

1 . Allocating memory automati- 
cally between the programs. This 
requires that programs be assem- 
bled in a relocatable form and 
have a preface that enables the 
operator program to organize the 
program, its data, and its use of 
common subroutines. 

2. Recovery from stops and 
loops. The best solutions to these 
problems require: 

a. Changing the stop instruction 
to trap instructions. This is a 
minor modification to the ma- 
chine. (At least it will be 
minor for the 704.) 

b. Providing a real-time alarm 
clock as an external device. 

3. Preventing a bad program 
from destroying other programs. 
This could be solved fairly readily 


with a memory range trap which 
might not be a feasible modifica- 
tion. Without it, there are 
programming solutions which are 
less satisfactory but should be 
good enough. These include: 


a. Translations can be written 
so that the programs they 
produce cannot get outside 
their assigned storage 
areas. A very minor modifi- 
cation would do this to 
Fortran. 

b. Checksums can be used for 
machine language programs. 

c. Programming techniques can 
be encouraged which make 
destruction of other programs 
unlikely. 

d. There is an excessive ten- 
dency to worry about this 
point. The risk can be 
brought down to the present 
risk of having a program ru- 
ined by operator or machine 
error. 


Summary 

a. We may be able to make a 
major advance in the art of '■"'-■f 
using a computer by adopting • 
a time-sharing operator pro- 
gram for our hoped-for 709. 

b. Such a system will require a 
lot of advance preparation 
starting right away. VrV " ?C: 'Air: 

c. Experiments with using the 
Flexowriter connection to the 
real-time package on the 704 
will help, but we cannot wait 
for the results if we want a 
time-sharing operator pro- 
gram in July 1960. 

d. The cooperation of IBM is 
very important, but it should 
be to their advantage to de- 
velop this new way of using a 
computer. 

e. I think other people at MIT 
than the Computation Center 
staff can be interested in the 
systems and other engineer- 
ing problems involved. 


perhaps for two reasons. The first reason was that our initial 
cost estimates were very large for reasons of conservatism. 
Second. IBM asked MIT to wait, saying that they would 
..‘•■ike a proposal to meet MIT’s needs at little or no cost. 
Unfortunately, the System/360 design took longer than IBM 
management expected, and along about that time, relations 
between MIT and IBM became very strained because of the 
patent lawsuit about the invention of magnetic core mem- 
ory. 

As pan of the stall, president Stratton proposed a new 
study with a more thorough market survey to establish the 
demand for time-sharing among MIT computer users. I 
regarded this as analogous to trying to establish the need for 
.'cam shovels by market surveys among ditch diggers, and 
'■ did not want to do it. About this time George Forsythe 
invited me to come back to Stanford with the intention of 
building a Computer Science Department, and I was happy 
to return to California. 

In all this, there was not much publication. I wrote a 
memo to Morse dated January 1, 1959, proposing that we 
time-share our expected '‘transistorized IBM 709.” It has 
been suggested that the date was in error and should have 
■cen 1960. 1 do not remember now, but I believe that if the 
memo had been written at the end of 1959, it would have 
reterred to the 7090, because that name was by then current. 
In that memo I said the idea of time-sharing was not espe- 
cially new. I do not know why I said that, except that I did 


not want to bother to distinguish it from what was done in 
the SAGE system with which 1 was not very familiar. 

Most of my argumentation for time-sharing was oral, and 
when I complained about Fano and Corbato crediting 
Strachey with time-sharing in their 1966 Scientific American 
article, Corbatd was surprised to find my 1959 memo in the 
files. Their correction in Scientific American was incorrect, 
because they supposed that Strachey and I had developed 
the idea independently, whereas giving each user continu- 
ous access to the machine was not Strachey’s idea at all. In 
fact, he did not even like the idea when he heard about it. 

Teager and I prepared a joint abstract for an ACM 
meeting shortly after he arrived, and I gave a lecture in an 
MIT series called Computers and the World of the Future?* 
In this lecture I referred to Strachey’s paper “Time-sharing 
in Large Fast Computers” 43 given at the 1959 IFIP Congress 
in Paris. I had read the paper carelessly, and supposed he 
meant the same thing as I did. As he subsequently pointed 
out, he meant something quite different that did not involve 
a large number of users, each behaving as though he had a 
machine to himself. As I recall, he mainly referred to fixed 
programs, some of which were compute bound and some 
input-output bound. He did mention debugging as one of 
the time-shared activities, but I believe his concept involved 
one person debugging while the other jobs were of the 
conventional sort. 

My 1959 memo advertised that users generally would get 
the advantage of on-line debugging. However, it said noth- 
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ing about how many terminals would be required and where 
they would be located. 1 believe I imagined them to be 
numerous and in the users' offices, but I cannot be sure. 
Referring toan “exchange" suggests that I had in mind many 
terminals. 1 cannot now imagine what the effect was on the 
reader of my failure to be explicit about this point. I'm afraid 
1 was trying to minimize the difficulty of the project. 

The major technical error of my 1959 ideas was an un- 
derestimation of the computer capacity required for time- 
sharing. I still do not understand where all the computer 
time goes in time-sharing installations, and neither does 
anyone else. 

Besides MIT's NSF proposal, there ought to be some 
letters to IBM and perhaps some IBM internal documents 
about the proposal, since they put more than a million 
dollars worth of equipment into it. Gordon Bell discusses 
DEC’S taking up time-sharing in the Bell/Newell book." but 
I do not recall that they discuss Ben Gurley's role. Fredkin 
and perhaps Allan Kotok would know about that. 

After I came to Stanford. I organized another PDP-i 
time-sharing project. This was the first time-sharing system 
based on display terminals. It was used until 1969 or 1970 
for (Patrickj Suppes' work on computer-aided instruction. 

Excerpts from “Man-Computer 
Symbiosis ” 28 

About the .same time McCarthy was writing his memoran- 
dum to Morse on the mechanics of time-sharing. J.C.R. 
Licklitler was investigating the concept of man-computer 
symbiosis, a premonition of man-machine cooperation which 
is even today not wholly achieved. The following selection 
from Licklider's " Man-Computer Symbiosis" is reprinted 
with permission from IRE Transactions on Human Factors 
in Electronics. March I960 ( Z 1960 IRE (now IEEE)). 

Man-machine symbiosis is an expected development in 
cooperative interaction between man and electronic com- 
puters. It will involve close coupling between the human and 
electronic members of the partnership. The main aims are 
I) to let computers facilitate formulative thinking as they 
now facilitate the solution of formulated problems, and 2) 
to enable man and computers to cooperate in making deci- 
sions and controlling complex situations without inflexible 
dependence on predetermined programs. In the anticipated 
symbiotic partnership, men will set the goals, formulate the 
hypotheses, determine the criteria, and perform the evalu- 
ations. Computing machines will do the routinizable work 
that must be done to prepare the way for insights and 
decisions in technical and scientific thinking. Preliminary 
analyses indicate that the symbiotic relationship will per- 
form intellectual operations much more effectively than 
man alone can perform them. Prerequisites for the achieve- 
ment of the effective, cooperative association include devel- 
opments in computer time-sharing, in memory components. 


* More likely: CG. Bell. J.C. Mudge. and J.E. McNamara. Com- 
puter Engineering. Digital Press. Bedford. Mass.. 1978. 


in memory organization, in programming languages, and in 
input and output equipment. 

In one sense of course, any man-made system is intended 
to help man. to help a man or men outside the system. If we 
focus upon the human operator(s) within the system, how- 
ever. we see that, in some areas of technology, a fantastic 
change has taken place during the last few years. “Mechan- 
ical extension" has given way to replacement of men. to 
automation, and the men who remain are there more to help 
than to be helped. In some instances, particularly in large | 
computer-centered information and control systems, the ? 
human operators are responsible mainly for functions that \ 
it proved infeasible to automate. Such systems are not svm- \ 
biotic systems. They are “semi-automatic” systems, systems i 
that started out to be fully automatic but fell short of the i 
goal. { 

It seems entirely possible that, in due course, electronic \ 
or chemical “machines’’ will outdo the human brain in most \ 
of the functions we now consider exclusively within its prov- i 

ince. 

It is often said that programming for a computing ma- ! 

chine forces one to think clearly, that it disciplines the i 

thought process. If the user can think his problem through | 
in advance, symbiotic association with a computing machine 1 
is not necessary. i 

However, many problems that can be thought through in | 
advance are very difficult to think through in advance. They 4 
would be easier to solve, and they could be solved faster. \ 
through an intuitively guided trial-and-error procedure in i 
which the computer cooperated, turning up flaws in the 
reasoning or revealing unexpected turns in the solution. | 
Poincare anticipated the frustration of an important group | 
of would-be computer users when he said “The question is J 
not ‘What is the answer?' The question is ‘What is the | 
question?"' One of the main aims of man-computer svmbi- I 

osis is to bring the computing machine effectively into the | 
formulative parts of technical problems. The other aim is i 
to...bring computing machines effectively into the processes J 
of thinking that must go in “real time." time that moves too | 
fast to permit using computers in conventional ways. 

Later Licklider was instrumental in not only initiating the % 
concept of an extensive project which would have similar aims J 

to those expressed in his I960 paper, but also he was in a j 

position to provide the funding for that work! His train ride | 

with Robert Fano from Hot Springs, Va„ to Washington, 

D. C. ( probably aboard the “Crescent") gave them the oppor- 
tunity to realize that ARP A needs could be met through the 
capabilities of the MIT group. In our interview with Licklider 
and Fano we asked them of their recollections of this trip. 


Teager’s recommendation tor an IBM 
7030 48 

The two studies that preceded the formalization of the 
MIT activity, which led first to the development of the Com- 
patible Time-Sharing System ( CTSS) and eventually to Proj- 
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ect MAC. have been mentioned both by McCarthy in his 
recollections and later by the respondents in the interviews. 
The first study group report, written by Herbert Teager, 

• nnmended the acquisition of an IBM 7030 (Stretch), 

■ .ugh Teager recognized that he was unable to obtain all 
.. .v necessary data regarding its capabilities, and the support 
software was an unknown factor. Retrospectively, Teager's 
arguments were sound; his choice of the IBM Stretch was 
unfortunate. 

MIT should obtain, within the next two to three years, 
an ultra large capacity computer, develop time-shared re- 
mote input-output facilities complete with display and 
: .iphical input capability, and begin an intensive effort to 
. elop advanced, user oriented programming languages 
:or this system. This policy would seem the best possible way 
tor MIT to obtain a research facility to multiply the intellec- 
tual effectiveness of the experimental and theoretical re- 
search workers and teachers in all fields. The policy would 
at the same time provide a necessary experimental tool for 
frontier research in many fields involving physical simula- 
tion, information processing, and real-time experimental 
work, which would otherwise be unfeasible. 

The machine should have sufficient capacity and be of 
.i.ficientlv advanced design so that it would have a useful 
: >0 of at least six years, before any further change need be 
contemplated. 

Based upon presently-published specifications for exist- 
ing machines, the IBM 7030. Stretch Computer is a suitable 
candidate for the recommended computer, by virtue of its 
speed, memory size, and overall capacity and capabilities. 

Published data for Stretch, while not including some 
important, but presently unknown factors such as reliability 
T.d mean, error-free running time, does indicate that the 
'utmercial version of this machine will come very close to 
noting its specifications. Several have been built, and pro- 
grams are operating on this machine as the last of the “bugs" 
are being wrung out. Other announced machines are either 
unsuitable or else are in such an early stage of development 
that specifications and costs are too vague for an objective 
appraisal. 

The final decision for the central computer should be 
made on a basis of its installation within a maximum period 
0 : perhaps three years [emphasis added): a minimum set of 
-n :ed. reliability, memory size, and overall capacity require- 
ments: and finally the relative cost for such unit capacity. 
Presently unknown commercial machines might conceiv- 
ably prove a better choice if they could meet these criteria, 
and in any event other manufacturers should be given a 
chance to bid. 

In order to properly prepare for such a machine, it is 
believed that the machine design and programming specifi- 
cations would have to be firm within a year at most. Before 
IBM or any other computer manufacturer can be directly 
T reached at a high level for performance specifications 
J,1 “ bids, it is believed that an early policy decision with 
respect to MIT's intentions is necessary'. 

The present trend towards additional separate comput- 
ers would appear an unsatisfactory overall solution to MIT’s 


problems in this area from a standpoint of both cost and 
overall performance. Far more serious, however, is the fact 
that the chance to provide the needed capacity in the form 
recommended by this Report may well become impossible 
in the face of the developments and acquisitions of these 
many divergent groups unless a decision is made very soon. 


Making the capacity of a powerful 
machine more directly available to 
each user will multiply its 
effectiveness and eliminate the 
drawbacks of a large central machine. 

Analyses based upon costs and characteristics of existing 
commercial machines made during the course of this study 
tend to show that computer capacity is far more economi- 
cally provided by a single, very large capacity machine, 
rather than by many separate medium- to small-scale ma- 
chines. In addition, there are vital research problems scat- 
tered in all fields of interest to the Institute which must have 
vast memory sizes and extremely high processing speeds if 
they are to be solved within feasible running times. Separate 
machines which may have either a vast memory or high 
speed are thus highly inefficient and overly costly both in 
total time and money for the solution of these problems. 
Providing a capacity of the type necessary can most econom- 
ically be achieved by the rental or purchase of the largest, 
fastest available commercial machine such as the IBM 
Stretch computer. There is. at present, no other existing 
machine or combination of machines that can achieve com- 
parable computation costs and rates. 

Making the capacity of a powerful machine more directly 
available to^each user will multiply its effectiveness, and 
eliminate the drawbacks of the use of a large central ma- 
chine such as have been experienced at MIT. The MIT 
Computation Center is as well administered as any other 
comparable facility with a load of similar nature and magni- 
tude. Nearly 400 distinct problems are active at the Center 
at any given time, and to fairly distribute the available time, 
amounting to less than half of that requested, among large 
numbers of anxious users, leads to difficulties. These be- 
come even greater as nearly 100 competing users attempt to 
use the machine on an average day. The net result from the 
user’s viewpoint is excessive paper work to achieve inade- 
quate time grants, long turnaround times between program 
submission and results, and thus, an overall slowdown in 
research. There would be little justification for an extremely 
high capacity central facility which compounded these 
shortcomings on a larger scale. Fortunately, however, there 
is strong technical evidence that it need not. 

While some of the faculty members are aware of com- 
puters and programming developments with a potential 
application in their field, they are even more aware of the 
present usage difficulties. Programming for them, even in 
the so-called advanced languages, tends to be tedious, not 
easily applicable to their own work, and requiring knowl- 
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edge ol lar loo many conventions and exceptions. Other 
obstacles are the uninterrupted hours required to program 
and debug belore finally getting any results, in the face of 
an overcrowded faculty day. and an overworked facility. 
They cannot allord to wait for the presently necessary weeks 
of elapsed time between problem formulation and machine 
solution. 

The difficulty of administering a large central machine 
can only be overcome if a time-shared central machine is 
brought out to many simultaneous users in the form of 
remote input-output "consoles" which have all the charac- 
teristics ol a user's own personal computer with respect to 
access, a known available capacity, and a minimum of usage 
formalities. Such a console would provide far more capacity 
and capability than the user could afford for the same cost 
in a machine of his own. [See Figure 2.] Such capacity, in 
addition to speed, would allow the user to "program" in 
languages that are closely allied to that of his field, and in 
addition, eventually allow him to use pencil and paper 
should he dislike or be unable to use a keyboard to commu- 
nicate his problem to the machine. It would also provide 
graphical display and a permanent record of all work: such 
capability would go a very long way towards attracting a 
sizable traction of the faculty who could use computers" to 
extreme advantage, but who cannot spare the protracted 
time requirements ol present usage, as well as realizing the 
benefits of computers as a classroom aid. 

During evenings, nights and weekends, the system de- 
scribed would have adequate capacity to run verv large 
problems, which might require the total capacity of the 
central machine, or the work of groups which might not be 
compatible with or desirable for time-sharing. This would 
be a minor restriction upon such groups. 

Although development programs are already underway 
tor the high capability, low-cost console described, time- 
sharing techniques and remote input-output stations 
equipped with typewriters presently exist. A large part of 
the access problem described can be solved today" with very 
little further development, and thus the entire program does 
not hinge on the possible gamble that to develop the high- 
capability languagesand facilities might take longer than the 
indicated three-year time period. To provide “the central 
facility will be costly, as will the programming effort to 
provide the needed languages, and to a lesser extent the 
development and procurement of a large number of high- 
capabilitv remote facilities. But it would" seem the cheapest 
wav of providing the needed capacity, and the only wav of 
providing the necessary, close man-machine interrelation- 
ship which is felt vital for research in the years to come. 

One of the most common complaints made bv users in 
the course of the survey of all MIT research projects was that 
it was extremely difficult to find competent programmers, 
who could translate their desires into machine programs. 
This is a symptom of a much longer range problem, i.e., 
non-faculty usage, and calls for a longer range solution. 

For any intellectual tool to be used, it must have a 
response time roughly comparable to that of the person 
using it: otherwise it may well slow down, rather than speed 
up. the overall rate of the man and machine. The net result 


will be that the user does not use the tool, even though it 
could be of material assistance to him. 

It is believed that the relatively small percentage of the 
I IT faculty who are using computers directly, and the 
rather limited amount of such usage, is due primarily to the 
tedious nature of present day programming languages and 
the inescapable fact that it requires a minimum o“f 2-4 weeks 
to get a moderately complex program written in the best 
available language to operate... For most senior researchers 
this time lag provides a sufficiently strong barrier to keep 
them from using machines at all. 

Much has already been made in this study of the fact that 
i 1IT faculty are not directly using computers but are rather 
working through middlemen, in the form of research staff 
and graduate student programmers. More will be made of 
the ineptitude of present languages, which results in many 
debugging and compiling runs before a problem is finally 
ready tor the “production" which was its raison d'etre. Due 
to present administration policies and computation loads, 
most of the total elapsed time in getting to production is 
spent tn the presently inevitable [emphasis added] waits of 
turnaround times between submissions in the succession of 
reruns. 

The net result is to force highly skilled personnel to 
remain idle tor long periods of time, unless sufficient ma- 
chine time is granted so that they are working on several 
problems at the same time, but having to constantly "shift 
mental gears and rethink programs. 

As their efficiency decreased (due to the long turnaround 
times and small time grants) so does morale, and not having 
the satislaction of seeing their work come to earlv fruition” 
the best of them leave. 

No study was made of this area, but from many personal 
contacts and discussions it is estimated that no croup at MIT 
can expect to hire and keep good qualified procrammers for 
much longer than about 1 ^ years. Many groups have suf- 
fered almost 100 per cent casualties inside of three vears. 
This is not. it is believed, a question of salaries. 

The effect of such a turnover rate, the constant loss of the 
best and most talented people, and the training of far less 
capable ones to take their place are highly detrimental and 
costly to the research work of MIT. This problem too, it is 
believed, can be alleviated. 

In the past, many cogent and pressing arguments have 
been presented for separate small- to medium-scale comput- 
ers for use by many of the research groups around Tech. 
Although a variety of reasons have been given for this form 
of private enterprise, the basic reasons it is believed are ones 
of access and possession. A researcher in general regards a 
computer as a tool (ranging in power from an intelligent 
assistant to a desk calculator, depending upon his inclination 
and familiarity) and. as with all other tools, feels that its 
effectiveness is measured in part by his degree of access to 
it. and the degree to which he can count on using it when he 
wants to. If it is located in close proximity to his other work 
all the better. 

It is thus believed that the only fair and workable ar- 
rangement to divide the large machine’s capacity is to assure 
each large user a fixed minimum share of the large machine’s 
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capacity, on call to him at any time he needs it, so that it has 
all the properties of a personal machine. If properly com- 
bined with remote facilities and languages, the user will be 
much happier with a percentage of a larger, and far more 
efficient data processor, than he would be with a much more 
::mited capability machine of his very own. After all, as far 
‘ s concerned, there would be no way of telling the 
Terence, outside the fact that the time-shared facility 
would be far less costly to him. far easier to administrate, 
and much more powerful. 

There is every indication that MIT will need at least a 
20-100 fold increase in its available computer capacity 
within the next three years if it is to continue and accelerate 
its use of computers as an intellectual tool for research and 
teaching. The major alternatives for providing this capacity 
‘••re the following: 


!• Continue the present policy of allowing separate 
groups to provide their own separate facilities as pres- 
ent computer 'facilities become less and less able to 
meet their requirements. 


2. Purchase or rent an extremely large central ma- 
chine with adequate remote facilities to satisfy the 
projected needs and requirements of the various 
user groups. 

3. Design or build our own large computer that would 
have the same or better capacity as would be provided 
by a machine that is available commercially, using 
presently existing components and machine organiza- 
tion techniques. 

4. Designing or build our own large computer, using 
“state of the art" components, and the most advanced 
concepts of machine and system organization that can 
be obtained from the foremost experts in the field, 
whether they are at MIT, Lincoln, Rand, or else- 
where. 

Of these major alternatives, buying a suitably modified 
commercial machine, and in particular Stretch, seems by far 
the most advantageous. 
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Minsky and Teager 

Interestingly, in the workshop 
which formed the basis for the book 
Computers and the World of the Fu- 
ture by Martin Greenberger, 
McCarthy says 


The material I shall present 
on computer-system design 
was developed jointly with 
Marvin Minsky. I also want 
to acknowledge the stimulat- 
ing effect of discussions 
with Professor Herbert M. 
Teager and Dr. F.J. 

Corbato, who are develop- 
ing time-sharing systems for 
the IBM 7090 at the MIT 
Computation Center. 

This contains one of only a few 
references to Marvin Minsky’s con- 
tribution to the development of the 
concept; one other reference is in 
one of the translations of "MAC" 
provided by Peter Elias: 


Machine Aided Cognition 
Man And Computer 
Minsky Against Corbato 

Others have also provided Multiple 
Access Computer. 

McCarthy also implies, and this 
was confirmed during the inter- 
views, that Teager was proceeding 
with his own plans in parallel with 
Corbato. Teager’s work was de- 
scribed in the Communications of 
the ACM in a 1 962 reprint 49 of an 
earlier research report; “Real-Time, 
Time-Shared Computer Project,” 
Computation Center and Research 
Laboratory of Electronics, MIT, 
Cambridge, Mass. Reported by Her- 
bert M. Teager (Nov. 1961). Some 
excerpts follow (copyright 1962. As- 
sociation for Computing Machinery, 
Inc., reprinted by permission); 

The objective of this proj- 
ect is to develop devices, 
systems, and languages for 


the fruitful interaction be- 
tween scientists and 
computers, using the com- 
puter as a powerful, on-line 
aid to understanding. Due to 
cost and computer capacity 
considerations, this ability 
can best be provided within 
the context of time-sharing a 
slightly modified, standard 
memory size computer, 
equipped with random ac- 
cess files, among many 
low-cost simultaneously oper- 
ating remote consoles, each 
equipped with low data rate 
graphical and character-pro- 
ducing input-output devices. 

The major accomplish- 
ments of this project over the 
past calendar year are the fol- 
lowing. On-line programming 
and computation utilizing a 
system of multiple indepen- 
dent typewriters has been 
tested. An existing digital plot- 


Long Range Computation Study 
Group’s recommendation for a 
time-sharing system . 1 

flic conclusions anti recommendations of the Teager re- 
port did not reflect the views of the majority of the committee. 
I hits, a second report was submitted that recommended the 
net/ nisi tion o f not just a large computing system, but also a 
system capable of supporting timesharing. 

I he second report of the Long Range Computation Study 
Croup was presented to Albert llill in April 1961. 

The major part of MIT's computational needs, a few 
years from now. can best be met by a single very high speed 
large-capacity computer system with provision for time- 
sharing through a number of remote consoles. 

Present estimates of the cost of such a system lie between 
$8 and $25 million for a suitable central machine, including 
the development and procurement of remote input-output 
equipment, and the development of programming lan- 
guages and systems appropriate for time-shared operation. 
However, this system would be the cheapest way of provid- 
ing the needed capacity and the only way of providine the 
necessary, close man-machine interrelationship that we feel 
is vital for research in the years to come. 


% The committee is convinced that the bulk of scientific 
calculation is certain to increase rapidlv and that it would be 
uneconomical, even if feasible, to try to keep pace with this 
growth by the addition of more and more standard ma- 
chines. although there are areas in which separate machines 
maybe valuable. Therefore, steps should be taken to acquire 
a giant machine meeting the specifications presented subse- 
quently. 

Tile conclusion that a central computer nith remote con- 
soles is required is based not only on the important economy 
obtained, both in running expenses and in programming ex- 
penses. but also on the importance of establishing close com- 
munication between the scientist and the machine. Thus, the 
committee feels that it is essential to provide for operating the 
machine in a time-sharing mode to provide immediate service 
to each of a large number of users simultaneously operating 
remote consoles throughout the Institute. 

It IS remarkable that, despite the many views and needs 
represented by members of the committee, there were es- 
sentially no compromises involved in coming to this general 
conclusion. Such a high-speed computing system having a 
very large memory and remote time-sharing operation 
meets the needs of very different kinds of pro; Jets, ranging 
from the numerical computations or physics, engineering 
and meteorology, to the symbolic computations of language 
translation and artificial intelligence projects. 
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ter has been connected to 
the IBM 709 computer, and 
a special-purpose computer 
to control multiple indepen- 
dent plotters is being 
constructed. A prototype of 
a high resolution graphical 
input device for hand-drawn 
figures and symbols is 
being built. Design modifica- 
tions to trie 7090 computer 
have been proposed and are 
being incorporated in our 
forthcoming machine. Sched- 
uling systems for 
time-sharing and memory al- 
location nave been simulated 
and found satisfactory. An in- 
formation retrieval system for 
programs and data is being 
designee. Programming sys- 
tems to ailow handwriting as 
a valid input are being 
checkea cut, and new graphi- 
cal languages for several 
major prcblem classes for 
input and output have been 
partially soecified. 


REFERENCES: 

Teager, H. Dec. 1960. Mar- 
riage of on-line human 
decision with computer pro- 
grams. Naval Res. Logist. 

Quart., 379-383. 

As indicated in the interviews later, 
Teager apparently concentrated on 
the design of interactive input-output 
devices connected to the IBM 709 at 
the same time as Corbato was imple- 
menting CTSS on the same machine. 

In the above communication, Tea- 
ger refers to a prior paper presented at 
George Washington University in 
1 960, which appears to provide the mo- 
tivation for his work. This motivation, 
typified here by the abstract from that 
paper, has a strong resemblance to 
Licklider’s man-computer symbiosis 
concept. 

As the logistics problems of cur- 
rent interest become more and 
more complex, it becomes ap- 
parent that heuristic methods 
hold more promise than exhaus- 
tive or algorithmic methods of 


solution. It is also becoming 
clearer that heuristics, per se, 
are useless in approaching 
large combinatorial problems 
(via pattern recognition, for 
example), unless some gen- 
eral techniques are 
developed to draw out the 
specific “best” heuristics re- 
quired for each problem. It is 
a fact that humans are, at 
present, far more efficient in 
developing and applying 
such heuristics than a ma- 
chine. It is therefore of 
considerable value to explore 
how the best features of both 
human and machine decision 
can be married. The general 
problem requires the develop- 
ment of common meaningful 
languages, specialized input- 
output display and entry 
facilities, and a means of 
time-sharing the computer, in 
order to efficiently match 
the machine versus the 
human-decision time. 47 


r v:islbility of propo.sed system 

.Aii components of the propo.sed central computer sys- 
tem either exist or can be developed during the time neces- 
sary for the procurement of the central computer. For ex- 
ample. time-sharing arrangements using remote 
input/output stc.ions equipped with typewriters presently 
exist. Further study is needed in the areas of console speci- 
tications. programming languages and system administra- 
tion. but the Study Group is confident that the present 
commendations are not dependent upon the results of 
■ -tudies. Ir. defining these areas, it is merely recoeniz- 
me need to present a full picture of future work. 

The final choice for the central computer should be based 
on whether it can be installed in three years and will meet 
the set of general specifications [presented in Part III of this 
report). There are two feasible alternate wavs to acquire 
such a computer. The first is to purchase or rent one of the 
very large commercially available computers, such as the 
IBM 7030. commonly known as "Stretch." With minor mod- 
' ‘ “ u ' ons an d provisions of time-sharing facilities, this com- 
er will mec: many of the requirements. The second 
-■-.cl native is to nave a manufacturer construct a computer 
recording to our specifications, making full use of any ad- 
^anced components which he may have. 


It is not possible at this time to make any kind of firm 
cost estimate, since the committee has not yet been in direct 
contact with manufacturers. A suitable system based on the 
IBM Stretch computer would, at rumored prices, cost be- 
tween S20.000.000 and $25,000,000. Much of this cost would 
be the cost of memory. Some of the members of the com- 
mittee believe that the cost of a suitable system may be as 
little as seven or eight million, but others are not convinced. 


The importance of time-sharing 

The main conclusion of this report is not just that MIT 
acquire a very large computer system, but that the computer 
system be a time-sharing one. accessible to its users through 
remote consoles and accessible to laboratory apparatus 
through suitable data transmission facilities. The reason for 
this emphasis on time-sharing is because the greatest short- 
age at MIT is not in computer speed but in interaction 
capability with the users and with the users’ laboratories. In 
fact, the increase in interaction capability made possible by 
the time-shared system will have as much impact on MIT 
research as the introduction of automatic computation in 
the first place. 

A single, very' large, time-shared system is recommended 
for the following reasons: 
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1. Only a very large computer can satisfy the needs of 
users with very large problems. 

2. Only a time-sharing system can make possible effi- 
cient use of large capacity by many small users. 

3. Only a very large secondary storage system can con- 
tain all programs and data and make them rapidly 
available to the computer under the control of simple 
consoles. 

4. Only a single large system with many users can pro- 
vide a sufficient base to support the large effort re- 
quired to provide advanced public programs to all 
users on an adequate scale. 

5. Only a time-sharing system can provide the interac- 
tion capability which, especially when combined with 
advanced programming and control languages, is so 
essential to improved computer utilization in re- 
search. 


Specifications for central computer 

The general scale and characteristics of the central com- 
puter are indicated by the following specifications: 

1. An advanced indexing and addressing system, fixed 
and floating point arithmetic, and a full complement 
of logical and variable length operation. 

2. Average program running speed of at least 10 6 in- 
structions per second. 

3. 250.000 to 1,000.000 words of directly addressable 
memory, each word at least 48 bits. 

4. Full time-sharing facilities including memorv protec- 
tion. interrupt capability, and non-stop operation. 

5. Provision for a system of remote consoles. 

6. Capability for real-time interaction with laboratory 
apparatus at a rate of 250.000 words/sec. 

7. Secondary storage of more than 10 7 words with an 

access time of about .1 sec. and a data rate of 250.000 
words/sec. ■ 
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CTSS — The Compatible Time-Sharing 
System 


I mmediately after — if not before — the presentation of 
the Long Range Computation Study Group report to 
Albert Hill. Fernando Corbato began to develop an exper- 
imental system that would show the feasibility of a time- 
shared system such as that envisaged by several members of 
the group. Within a very short time, he was able to demon- 
strate the first steps in this direction, as shown in the follow- 
’>? excerpts from a 1962 paper he coauthored with Marjorie 
."win-Daggett and Robert C. Daley. The selection from 
■••■>4 paper, which reported work completed in late 1961, is 
reprinted from Pw. Spring Joint Computer Conf. Vol. 21 
(© 1962 AFIPSi. 

Excerpts from “An Experimental 
Time-Sharing System ” 14 

Before proceeding further, it is best to give a more 
...ise interpretation to time-sharing. One can mean using 
• ' -rent parts of the hardware at the same time for different 
tasks, or one can mean several persons making use of the 
computer at the same time. The first meaning, often called 
multiprogramming, is oriented towards hardware efficiency 
in the sense of attempting to attain complete utilization of 
all components. The second meaning of time-sharing, which 
is meant here, is primarily concerned with the efficiency of 
persons trying to use a computer. Computer efficiency 
'•’nould still be considered but only in the perspective of the 
' system utility. 

An experimental time-sharing system has been devel- 
oped. This system was originally written for the IBM 709 but 
has been convened for use with the 7090 computer. 

The 7090 of the MIT Computation Center has, in addi- 
tion to three channels with 19 tape units, a fourth channel 
with the standard Direct Data Connection. Attached to the 
Direct Data Connection is a real-time equipment buffer and 
control rack designed and built under the direction of H. 
I’cager and his group. This rack has a variety of devices 
;,r -vhed but the only ones required by the present systems 
. fl’.ree Flexowriter typewriters. Also installed on the 7090 
>irc two special modifications (i.e.. RPQ’s): a standard 60- 
cvcle accounting and interrupt clock, and a special mode 
which allows memory' protection, dynamic relocation and 


trapping of all user attempts to initiate input-output instruc- 
tions. 

In the present system, the time-sharing occurs between 
four users, three of whom are on-line each at a typewriter 
in a foreground system, and a fourth passive user of the 
background FAP-MAD-MADTRAN-BSS Monitor Sys- 
tem (FMS) used by most of the Center programmers and by 
many other 7090 installations. 

Significant design features of the foreground system [for 
the user] are [that he can]: 

1. Develop programs in languages compatible with the 
background system. 

2. Develop a private file of programs. 

3. Start debugging sessions at the state of the previous 
session, and 

4. Set his own pace with little waste of computer time. 

The foreground system is organized around commands 
that each user can give on his typewriter and the user’s 
private program files which presently (for want of a disc [sic] 
unit) are kept on a separate magnetic tape for each user. 

The commands are typed by the user to the time-sharing 
supervisor (not to his own program) and thus can be initi- 
ated at any time regardless of the particular user program 
in memory. For similar coordination reasons, the supervisor 
handles all input/output of the foreground system typewrit- 
ers. Commands are composed of segments separated by 
vertical strokes: the first segment is the command name and 
the remaining segments are parameters pertinent to the 
command. Each segment consists of the last 6 characters 
typed (starting with an implicit 6 blanks) so that spacing is 
an easy way to correct a typing mistake. A carriage return 
is the signal which initiates action on the command. When- 
ever a command is received by the supervisor, “WAIT” is 
typed back, followed by “READY” when the command is 
completed. (The computer responses are always in the op- 
posite color from the user’s typing.) While typing, an incom- 
plete command line may be ignored by the “quit” sequence 
of a code delete signal followed by a carriage return. Simi- 
larly, after a command is initiated, it may be abandoned if a 
“quit” sequence is given. I n addition, during unwanted com- 
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Location: 

Laboratory for Computer Science 
Fifth-Floor Conference Room 
Massachusetts Institute of Technology 
545 Technology Square 
Cambridge, Mass. 

Date: 

October 18, 1988 


f 


Interviewers: 

Robert Rosin, Editor, IEEE Annals of the History of Computing 
John AM. Lee, Editor-in-Chiet, IEEE Annals of the History of Computing 


Participants: 
Fernando J. Corbato 
Allan L. Scherr 
Douglas T. Ross 
Martin Greenberger 




O n the day following the celebration of the 25th anni- 
versary of Project MAC held in Cambridge on Octo- 
ber 16 and 17. 1988. two small groups of participants in the 
developments of CTSS and Project MAC met to exchange 
recollections about their activities. These interviews are 
•’rated into two parts, concentrating on each of the two 
-iopmental stages of time-sharing, although it was im- 
•' . " s, ^ e lo strictly maintain the separation since the discus- 
sions naturally overlapped the time periods. By choice, the 
interviewers guided the discussion to concentrate on the 
more personal and background aspects of this history, since 
the technological history has been well documented in the 
open literature. (See the References and Bibliography sec- 
tion on pp. 52-54.) The footnotes and reference citations 
‘•vere added during editing. 

biographical sketches — Corbato, 

Ross, and Scherr* 

Corbato: The war broke out in 1941 for the United States; 
our high school went into long hours and I saw a chance to 
get out in a hurry. 1 went to UCLA as a student with the 
threat of the draft looming over me. Suddenly some people 
came by who were concerned about the ability of the Navy 
o maintain and repair the incredible amount of electronic 
Jipment it was getting. There was a program called the 

VI ’ 'fceibcrger provided his biographical notes during the Proiect 

- interviews, which will appear in the next issue. 


Eddy Program, and they gave me the opportunity to join the 
program and get an education as an electronic technician. 
One of the benefits, of course, was one did not get drafted 
or get assigned to be a cook or something worse. So I 
enlisted at the age of 17 in the Navy and went through a 
year-long program as an electronic technician. I got exposed 
to some of the earliest and largest electronic systems then 
deployed in the Navy: mostly radars, lorans. and sonars. I 
got [exposure] both on land and on ship, and it was an 
incredible background experience. I did not realize until 
later how important that was. 

Lee: And how that experience paralleled that of other 
people in some respects in radar and other analog applica- 
tions? [Such as the wartime experiences of Maurice 
Wilkes. 33 ] 

Corbato: Yes, and it gave me a large-system perspective 
which was very, very important, and I view that as seminal 
in my own career. After the war I got a chance to go back 
to college. I went to Caltech. Since everyone wanted to be 
a physicist in those days, I wanted to be a physicist. Then I 
came to do graduate work at MIT, and I was still a physicist. 

I even got my doctorate in physics, but along the way I got 
exposed to digital computers by the late Philip M. Morse 
[later to be director of the MIT Computation Center]. He 
recruited me to take on a new research assistantship in the 
use of digital computers. That was approximately 1951. The 
people who signed on with this initial ONR-sponsored re- 
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search assistauiship program were exposed to punched 
cards in the spring, and in the summer we were exposed to 
Whirlwind. Whirlwind was just barely coming up: it had 
about 1.000 words of 16-bit memory. 

Rosin: ( ore memory by then? 

Corbato: No. a very fancy, custom-built electrostatic mem- 
ory that had a reliability [such that the] mean time between 
errors on a good day was about 20 minutes. 

Lee: Was that the William’s Tube? 

Corhulo: No. Jay Forrester was very prescient in recognizing 
that the William's Tubes were flaky in design, and he had 
actually gone back basically to first principles to design a 
very elaborate mosaic storage tube. Somewhat similar in 
storage retention (charge retention), but it was a tour de 
force in electronics to make it work — and they had to. 

R»ss: They built them in the basement at MIT. Patrick 
't out/ headed the group.'' 

Corhulo: They designed, built, and fabricated everything. 
The engineering design was good: it was tough — they had 
to rewrite everything every few hundred microseconds. I 
think. The cycle time on the memory was 24 microseconds. 
But it was a relatively fast computer for its day. and it had a 
nice lean order code — a RISC machine without realizing 
it. | Laughter. | There is no such thing as a non-RISC, right? 
That’s right. It had a 5-bit field for instructions so there was 
a maximum of 32 instructions. 

I got lo know people like Doug Ross w'ho were also the 
users of the day: I was a graduate student. I used the com- 
puter in mv physics doctoral work and got full exposure to 
using operating systems. 

Rosin: Whirlwind, of course, was government sponsored 
and had some really important work assigned to it. Was 
there a lot of campus computing ("nondefense computing’’ 
in today’s vernacular) going on at that time? How many 
graduate student colleagues were there who were using the 
machine? 

Corbato: Well, the people who ran it recognized the need to 
have unclassified work and [be able] to use it in a free way. 
So the deal they worked out was. to my recollection, approx- 
imately three to four hours a day. once in the late afternoon 
and once from 2 to 4 a.m. In the morning were the times 
when the nonclassified people were allowed a crack at using 
the machine. In fact. I did not really know very much about 
what was going on at that spot in time. This meant one 
worked all day and all evening preparing these Flexowriter 
tapes that were the input [media). Then one took a quick 
shot at the machine. And if you were really fast, you might 
get two shots in [during] that two-hour period. But it was 
perhaps one shot a day. Very frustrating, but on the other 
hand, the machine was not that big: the programs were not 
that huge yet. But the hours were all full. 


Lee: But did you regard it as a personal computer? 

Corbato: It was a personal computer; there were many 
things about it that got lost in the next few years, such as 
graphical display output and even audio output, in the sense 
that there was a probe put on the circuit of the accumulator 
which gave you a signature of every program you were 
running. You actually could hear where your program was, 
you could sense the loops, and you could even get the tempo 
of how the program was running. Occasionally, people rec- 
ognized from the audio that they had a program that was 
misbehaving because it did not do what they thought it 
should do at that point. 

After I got my doctorate in physics, Phil Morse recruited 
me into staying on with the newly formed Computation 
Center that he had begun in 1 956. But the space and machine 
did not really come together until the fall of 1957. For 
approximately one year, those of us who were working on 
the project with the new center were quartered in the Barta 
Building where the old Whirlwind was. The focal point of 
the new center was an IBM 704. Phil Morse had worked out 
a package deal with IBM. where in return for the use of the 
machine on campus for one shift, MIT would also make it 
available to a cooperative group of New England colleges 
for the second shift. Then the third shift would be retained 
for use by their [IBM’s] own local scientific office, and the 
fourth by a group in Cambridge which computed the orbits 
for the first sputnik. That group was formed and directed by 
Martin Greenberger. 

To make a long story short. I played various roles ranging 
from initially supervising a research assistantship program 
to later becoming assistant director, associate director, and 
finally deputy director of the Computation Center. 


Rosin: I think this is an opportunity to have Douglas [T.] 
Ross and Allan [L.] Scherr describe their backgrounds and 
how they got to be users of this same system that Corby has 
just been describing from his point of view as a service 
center. Doug, do you want to kick it off? Where did you 
come from and how did you get to the same point? 

Ross: Actually. I did undergraduate work at Oberlin. We 
have just finished having the 25th Anniversary Celebration 
of Project MAC. and I was telling people that my honey- 
moon night, the first night of my marriage, was spent in that 
very same Boston Sheraton Hotel used for this conference. 
[Laughter.] I came over to interview about coming here for 
math graduate school [laughter] in the fall of 1951. 1 had a 
better [financial] offer from Carnegie, but I decided MIT 
was the better [technical] place to be. 

I had a teaching assistantship on the way to a doctorate 
in pure mathematics in the Math Department, and my wife 
was the first "computer” hired at Lincoln Laboratory — 
meaning the first female punching a desk calculator! We’re 
very proud of her badge number (161). They worked out of 
Building 20 and also used a mechanical correlation com- 
puter designed by Norbert Weiner in the Servo Lab (Build- 
ing 32). They were using it for analyzing radar noise. She 
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had brought home a manual about it. and when the summer 
i 952 came along I needed a summer job. I do not know 
I siot the chutzpa. but I called up A I Sise. who was the 
. -.ecutive director of the lab. I said. "Hey. if you’ve got an 
electrical engineering student. I’m a math student, and by 
the end of the summer we could give you a much better 
calculator than that old ball-and-disk integrator thing! 
Would you be interested in that?"” He got back in a couple 
of days and said “Well, we can’t quite do that, but how would 
vou like to punch a calculator like your wife does?” So I said. 

• Fine, a summer job is a summer job.” 

One of the first things I had to do was check out the 
i.;ge results that they got with that analog computer 
v sit-re they set the smallest separation between the two 
tracing points. Two girls would each trace the data record 
with a point, and the computer would compute one point on 
the autocorrelation function. For a small shift, it kept corn- 
ins out unexpectedly. The engineers did not understand why 
it was so far off. I found out that there were a lot of other 
correlators around, both mechanical and electronic, but all 
of them were either broken or busy. 

Somebody said. “Why don’t you check it out on Whirl- 
, :.{j?” I said. “What’s that?" [Laughter.] I did not know it 
. ,.d spun off from the same lab and was now up the street 
in the Barta Building. Someone had told me that Jules 
Charney in the Meteorology Department had had a corre- 
lation program written by Jack Arnow (and I still have a 
copy of that program ). That was the first program I ever saw ! 
It was Jack’s program, and that same day I went downstairs 
and got the programming manuals from Donna Neeb and 
met John Frankovich (who just retired from Lincoln Lab 
hi< year). Within a couple of weeks I was a programmer. 

That’s all it took in those days. 

Ross: Yeah, right! [Laughter.] Anyhow, the upshot of it was 
that by the end of the summer I had completed an autocor- 
relation program which I was trying to debug. At that point 
Whirlwind was completely shut down for a couple of months 
while they yanked out all of the input/output system and put 
in a brand new one. in order to support the multiple displays 
and push-button inputs and so forth for the pre-S AGE Cape 
' id System. 51 

So I had time on my hands, and I started writing a Fourier 
transform program in order to be able to complete the job 
and actually get power density spectra out of the autocorre- 
lations. By the end of the summer. I had two programs that 
were partially debugged. I still had my two classes of Fresh- 
man Calculus to teach, and I had a full schedule of graduate 
school, but John Ward asked. “Do you really want to go 
back teaching freshmen, or would you like to consider 
making a career here?” I was the only mathematician in the 
b Doing that son of thing I could continue my work, study 
• ! special student, and get my degree — and everything 
would be wonderful. I said. “Yes, I think it is a good idea.” 
So that’s what I did. and by the time Whirlwind was back 
up. I was hooked. ' 

I think it's also appropriate that I give some thoughts 
here in the context of time-sharing. As a matter of fact, my 


memory is very faulty, so whenever I do these historical 
undertakings, trying to document them, I only put in what I 
can find in my own stuff. I’m not a scholar. I do not go to 
look at other people’s stuff except my own copies of the 
Comp Center reports and so forth, which are published. I 
do not go digging around elsewhere. I do try to only say 

“Within a couple of weeks I was a 
programmer.” 

“That’s all it took in those days.” 

things that I can actually document. Usually I find I am off 
by a couple of years. Things happened earlier than I thought, 
and I’m surprised by the sequencing and so forth. It’s really 
a fascinating, but time-consuming, chore to do this. Out of 
this particular early sequence came things that do feed 
directly into time-sharing. 

Rosin: Before we get to time-sharing. Doug, I would be 
interested in your reflections on the Comp Center as it 
emerged at MIT: it sounded, from what you were saying 
when Corby was talking, that you were a user, but when did 
you get to the other side of the input tray? 

Ross: I did not get to using the Comp Center yet. This was 
well before the Comp Center existed. I’m still four years 
before that. 

The key thing was that the job I was doing concerned 
very large scale data reductions for Air Force data. As soon 
as I found out about the classified work that Lincoln Lab 
was doing with Whirlwind. I managed to eventually get a 
tour to see all the multiple scopes and so forth, and decided 
that that was just what we needed to control our massive 
data reduction programs. They were so big and so multifac- 
eted that it was really hard to cram them through what had 
gone from IK of memory (16-bit electrostatic memory) to 
2K of magnetic memory. But they also had added a drum 
which had six more 2K banks worth of stuff, so you really 
had a lot of new things that we could use. Also, they doubled 
the speed of the machine when core memory went in. 

So we had these very large programs to run, and I 
commissioned John Frankovich and Frank Helwig (who 
were actually under Jack Porter, under Charlie Adams in 
the Whirlwind programming group) to write what later 
became called the Director Tape program — which is, I 
claim, the first operating system! That came about because 
the Flexowriter that was attached to Whirlwind had its 
paper tape punch, paper tape reader and printer hooked up, 
but when they installed a photoelectric tape reader, the 
mechanical reader was left unused. We had a tremendous 
shuffle of tapes to make our runs. So I had this idea that we 
could put those same manual instructions on a tape in the 
mechanical reader while we spliced together all our pro- 
grams on one big reel for the much faster photoelectronic 
reader — eliminate the manual operations and get more 
reliability. So Frank and John built such a system called the 
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Director Tape system, it was used also for controlling post- 
mortems. dumping the machine state. So that was. in effect, 
the lirst operating system, working along with the drum. I 
also wrote a mistake diagnosis routine that swapped chunks 
of memory to the drum and so forth, and that was part of the 
system. 

But then as the system grew, we started working on the 
use of the manual intervention consoles, with push buttons 
and analog displays. We switched from a 3D computational 
programming emphasis to what is now called "interactive" 
programming, hut l then called it "Gestalt programming." 
with man-machine conversation being the thrust of it. We 
had a couple of big demonstration meetings on it. But we 
still were working just with the push buttons that went with 
the Cape Cod control consoles that were in the secret Room 
222 in the Barta [Building). 

I did the first hand-drawn input to a computer (graphic 
input) in 1954. That was one of the few programs I wrote 
that worked the first time. I have a quotation of the opera- 
tors in the main control room saying. “What kind of a 
program do you have there? It sounded so strange." when 
they looked up on the scope and saw my handwriting with 
my name coming out. 

We were under way early using all this stuff, but we 
needed more language capability — ability to label displays 
and label plots and so forth — to get some true language 
control over what went beyond the push buttons. Starting in 
February 195b. I started working with the Whirlwind engi- 
neers to propose hooking the keyboard of a Flexowriter into 
the console, so we could put alphanumerics into the program 
on line. I 'mil then the keyboard had not been used, as near 
as I can ligure out. Arnie Seigel was an engineer as well as 
a programmer, and so he did a logic design, using relavs. We 
had a Flexowriter on its own rolling table, and a plug. We 
were not allowed to change any of the wiring on Whirlwind 
because of the importance of the Cape Cod work, so we did 
it without affecting anything in the electronics. 

I believe that same physical keyboard input hardware, as 
well as the design, was used bv Herb Teager and his group, 
when they decided to put a Flexowriter on the [Computation 
Center| IBM 704. In my Daily Resume book I mention the 
meetings between Dean Arden. Jack Gilmore. John Mc- 
Carthy. myself. Arnie Seigel. and whoever would be in 
charge of the Lincoln [IBM) 709 programming (no name 
given). sometime between December 29. 1957. and Januarv 
1958 in order “To consider using the real-time package 
(which was IBM's terminology) on the 709 to simulta- 
neously service about 20 Flexowriters in TX-0 fashion. We 
are going to start off with one Flexowriter on the 704 real- 
time package." I say in the Resume that keyboard as well as 
light-pen input was standard on the TX-0 all along. That was 
the start of MIT's time-sharing development. That's the tie 
that I thought would be appropriate to make here about how 
the Computation Center time-sharing efforts got underway. 


Lee: This [following) quotation is from the book A Century 
o) Electrical Engineering and Computer Science at MEP 1 — 
it talks about I960: “A proposal was worked out by John 
McCarthy and Marvin Minsky: other advanced ideas were 


proposed by Doug Ross. Jack Dennis, and Daniel Gold- 
berg. And then it goes on to say. "the report mentioned 
many students involved in the study, especially Allan 
Scherr. That was one of the reasons I felt that it was so 
important that we have a student of the era in this session to 
say. "How 1 got involved in this project.” 

Scherr: 1 came to MIT in the fall of 1958 as a freshman. I 
came with a general interest in electrical engineering that 
had started as a tinkerer with hi-fi systems, automobile 
electrical systems, and so on. when I was a high school 
student. In the second semester of my freshman year (this 
would be the February 1959 semester) John McCarthy and 
Nat Rochester, who was a visiting professor from IBM. put 
a freshman course together called something like “Introduc- 
tion to Automatic Computation." In fact. I can even remem- 
ber the course number: it was 6.41. A bunch of people got 
really excited about being in that course, so I signed up for 
it and got accepted. Apparently there was a much larger 
number ot people who had signed up than were accepted, 
but I got in! 

John and Nat wound up teaching us assembly language 
starting with a pseudomachine that Nat had invented called 
the "Rochester machine." Then later [they taught) FAP or 
SAP. I forget w r hich. on the [IBM] 704. then Fortran I (or 
II). and then John taught us Lisp. We ran class problems in 
all those languages. I recall almost being bitten by the pro- 
gramming bug. Most of the people in this course became 
instantly addicted to writing programs. A couple of the 
people Bunked out [of school) either that semester, or later, 
because all they did was spend all their time writing com- 
puter programs and did not go to [their] physics or math 
classes. As it turned out. I came away with a fascination for 
the hardware. So I did not do much with software for a while. 
Dean Arden was my freshman advisor, so Dean figures in a 
lot of this. 

It was not until the following year (which would have 
been 1960) that two rhings happened. One was that I met 
Herb Teager who was looking for skilled [chuckle] under- 
graduates to hire for a pittance to do computer work. I 
needed the money, so I applied. In those days there were 
two salary scales for undergraduates: if you were skilled you 
got $3.40 and if you were unskilled you got $3.20. If you 
knew how to program, that was considered skilled. Herb 
hired me to do some work for him. One of the things was to 
perform some of the measurements that were associated 
with the study that was going on about future systems. I sat 
at the console of the [IBM] 704 with a one-card self-loading 
program that Herb wrote. After every job was run, I would 
stop the machine and load this card in. and it would display 
how many zeros were in main (core) storage on the console. 

I d write that down, and by the end of the day we would have 
all these numbers that would show how big the programs 
were. [Laughter.] By subtracting the number of zeros and 
taking the 7’s complement (or the 8's complement), you 
could figure out how big the programs were. I produced a 
histogram on how big the programs were, and that was one 
of the things that went into the study. 
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From the audience: There's one point of confusion which is 
. that there were two long-range studies — Herb Teager 
. .no chairman of one. Herb produced a large report 4 * 
•„ ;nch got very little circulation — later we can get into what 
the problem was — and I think that the data that Allan was 
alluding to was gathered by Herb as reinforcement for his 
large report. There was subsequently a short report which 
was written by everyone but Herb, almost a rump report 1 
that had many of the same conclusions, but also differed in 
critical ways. That short report had almost no data to my 
recollection. 

.-bald: The data that Allan was referring to was part of a 
.,rue body of data which was produced by the committee, 
and it's sort of in the record but on the other hand it may 
not be noticed. 

Schern Interesting, because I was for the most part unaware 
of the controversy that was going on... 

Vudience: Hea\ \ politics. 

.nerr: Well, as we go through the day. I'm sure it will come 
out because there were some things that I wound up doing 
which were political also, at least as I found out later. 

Let me just say a few words about what it was like to use 
the Comp Center in those days. As a student, basically what 
you did was to write programs to do the usual kinds of things. 
In fact. I remember one of the exercises in this course [6.41] 
was to write a floating-point ADD in assembly language 
tbout using floating add instructions. We were supposed 
Use all the other instructions to simulate a floating-point 
•JD. and that was probably the hardest of the homework 
problems. I do not recall whether I ever got it to work, but 
basically all the students would submit their [program] 
decks, and they would be batched together and run under a 
main program that the instructors provided. That program 
would check to see whether you got the right answers and 
produce score sheets for each of the students. You'd wind 
up using 30 seconds of computer time for an entire home- 
•'••rk assignment. 

F:n actuaiiy not convinced that any operating systems 
•i-ice then have been faster than the ones we used in those 
days. The thought of assembling and running a program in 
a few seconds still boggles my mind. In those days there were 
peripheral machines that IBM provided that were basically 
card-to-tape. tape-to-printer. and so on. that were run as 
special-purpose machines. They were all in a glass house 
with the [IBM] ”04. It was probably a year later — 1959 or 
I960 — that we got [IBM] 1401s. The [IBM] 1401s came in, 
md there w&s a peripheral operation down in the basement 
building 26 -hat I vividly remember going down to. It 
really was a remote operation. The input/output station was 
oasicallv phy sicailv remote from the computer by a floor, so 
we would submit jobs down there and the output would 
come back somewhere else. 1 do not remember where any- 
more. The whoie idea w-as that programmers did not go into 
the machine room. 


Rosin: What was turnaround time on this? 

Schern A day — if you got two shots a day, it was a good 
day. 

“I’m actually not convinced 
that any operating systems 
since then have been faster 
than the ones we used 
in those days.” 

Rosin: Did you have to go back to find out whether your job 
was run? 

Schern Yeah, there would be people who would forecast 
when you should come back. Usually you would ask the 
operators. “How's turnaround time?” They would say, 
“Well, it's pretty good today. Why don't you come back at 
4 o’clock?" You would come back at 4 o’clock to see if you 
had got it and they'd say. "Come back later.” Then you 
would call up and say. "How is it going?" Mostly they didn't 
know, so what I would do [would be to] go to my classes and 
come back in the afternoon and see if it had come back, and 
if it had I would say "Great!" and if it had not. I'd go home. 
Writing programs in those days was a labor of love, and you 
wound up spending a lot of time at your desk because you 
did not want to waste the precious shot you were going to 
get once a day. 

Computing at MIT before CTSS 

Corbato: There were quite a number of people who were 
part of the initial new creation. One of them was John 
McCarthy, who first came as a visitor (from Dartmouth) as 
part of the New England Colleges Program and [who] then 
decided to switch to MIT as a faculty member. Dean Arden 
was on the faculty, and had been pan of the Whirlwind staff. 
Then he became part of the Computation Center staff. Herb 
Teager. who was a young assistant professor, was also part 
of the staff. 

In that environment. Phil Morse had tried to organize a 
dual role for the Computation Center. It was first a center 
of computer science research activities largely carried out 
by the faculty, and it was also a service center for both the 
MIT and New England college campuses. Part of the goal 
in those days was to try to encourage people to use the [IBM] 
704 in shrewd innovative ways. At First it was a little uphill. 
We had to sell people on the idea of how to use the machines. 
Fairly rapidly, as you would expect, we built up a good head 
of steam, and people began to use the computer. 

One of the first things that happened was that we began 
to get caught with the congestion of too many people trying 
to use the computer at one time. In the very early days, 
people tried to use the machine as we did Whirlwind, where 
you could go up to the machine with a deck of cards, read 
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them in. and run your job. A few minutes later, probably, 
you would lake a core dump (which had an incredible 
number of octal digits) and then go back and try to sort out 
what had happened. That was too inefficient for mass use 
and gradually we. and almost everybody else in the country 
using a machine of that character, switched to a mode which 
got to be called batch processing, where the input decks were 
collected in a group and prerecorded on a magnetic tape 
using an auxiliary computer, so that the magnetic tape was 
the input to the computer. It would run job after job. After 
each job finished, it would take a core dump, putting each 
out on magnetic tape, or when the [program] failed.'which 
they usually did... 

Schem ...At the exorbitant cost of 100 locations in lower 
core, which everybody complained about. 

Corbuto: The result was you had this kind of mail-order 
business, where you could drop off your deck. The closest 
to the computer you ever got was putting vour deck into a 
tray! Someone would pick the contents of the tray up and 
record them on tape. Then you would go and pick up your 
output in a file bin and ponder what in the world had 
happened. That style of operation persisted all the wav 
through i%4 or 1965. 

Rosin: Did you write your own primitive operating system 
or did you pick one up per se? You have to remember that 
IBM did not provide an operating system. 

| Here there was background discussion about whether that 
statement was true!] 

Corbuto: Let me see if I can give you my recollection of what 
happened. At first there was no operating system. Then 
there was something called the Fortran Monitor System 
(FMS). What happened was that just around the same time 
that we were to get our first computer. Fortran made a big 
splash. It had a major impact, of course. It opened the door 
to people who were intimidated by machine language. It 
enlarged the user base by a factor of 10 at least. One of the 
by-products of that system was that the people who devel- 
oped it organized a very simple-minded operating system 
called the Fortran Monitor System (FMS). and I do not 
know whether they, or whether we. inserted the assembler, 
which was called FAP (Fortran Assembler Program), into 
the same system. In that Fortran compiler implementation. 
Fortran source was translated to assembler language and 
assembled by FAP. SAP was the predecessor (Symbolic 
Assembly Program). The original effective name was very 
confusing. What was it assembling? It was assembling a 
library routine at first, but in fact the result was this subset, 
or successor . called FAP. specifically organized around link- 
ing the Fortran program. That became our de facto machine 
language. 


Rosin: How many users did you have? How many times 
could you run it in a day? What was turnaround time like? 


Corbalo: The number of registered users probably was in 
the several hundreds. Here I'm guessing, but we have the 
old manuals and one could dig it out of the old progress 
reports. 

Lee: Let me read something to you. This is from John 
McCarthy in Martin Greenberger's Computers and the 
Wor/dof the Future'- 3 [page 224] — so this is about 1 96 1 . John 
says. "Since the Computation Center is overcrowded, delay 
is more likely one or two days." 

Corbato. Let me explain that. \\ e were using somewhere on 
the order of three to five minutes for each job. So vou can 
figure oul for yourself how manv jobs that amounts to per 
day. ’ v 


Lee: [McCarthy] says 125 to 160 a day.* 

Corbato: We tried to use all kinds of pressure and persuasion 
(and just plain ordering) on people who had runs of longer 
than an hour (an hour was a big run ) to run that kind of stuff 
m the middle of the night and off-peak hours. But debugging 
runs were [different] — occasionally people would bomb in 
a minute and be in and out. but that was in the beginning. 

By 1964 or 1965. things sped up a little bit. and you could 
scale all those numbers down by a factor of 2 to 4. People 
were running faster jobs, they were in and out faster, but 
that s a detail. The critical problem was that the number of 
people trying to use the machine was sufficiently large that 
unless you had some pull or priority, which was verv reluc- 
tantly given out... 

Audience: I II say! [Chuckles.] 

Corbalo: ...you were faced with a minimum of two to four 
hours of waiting and fit was] much more likely to be an 
eight-hour wait before you got a repeat run — even if you 
were ready to turn the job back in instantaneously. Now 
frequently what would happen is that vou would not be 
sitting there waiting at the output bin. You would probably 
show up two hours after your job ran. You would then 
discover that you had to do some repair and/or analysis. It 
would take you maybe two to four hours to do that, even if 
it was pretty obvious. Finally, you would resubmit, and now 
you suddenly got to the back end of a queue and you could 
wait another four to six hours before it ran again and vou 
got it back and saw the results. You can see how that could 
easily escalate into 24 hours. In fact, that's what happened 1 
and that s what was driving people crazy. 

Rosin: (to Ross] Were you also a Comp Center user? f 

Ross: Oh, yes — my group was. I myself never even learned 
how to turn on a keypunch! During this time we were doing 
the APT system, work which started in 1 956." Although we 
started on Whirlwind, from the beginning the cooperative 
industry APT project was targeted toward the IBM 704 


* He probably meant per shift. 
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series, because that's what all the airplane manufacturers 
had. We were a very heavy user of the Comp Center right 
i the very beginning, even using some of IBM’s time, on 

_..usion. 

Rosin: What was your view of Comp Center service capa- 
bilities and so forth? 

Ross: Well, we had two roles really. I had known Corby and 
the others who were saddled with this responsibility. They 
had all sorts of things to balance that had never been done 
before. Also, they inherited the style [of programming] that 
:■ -i built up around Whirlwind — of having an in-house 
stem programmer group (nowadays we would call them a 
jystem group). They were the center programmers, and 
then there were the user programmers. There was a big 
difference because priorities were given to the inside people 
that the outside people could not get. So my group always 
was in the crack between the privileged and the ordinary 
users. We continued to push for more things because we 
were so big. We had a big job to do, so we did manage to 
wrangle deals. I did not get involved in that very much 
: ccpt just to say. "Yeah, you pinched us too hard. We’ve 
i *.o have some relief.” but normally we would be able to 
get some runs on an express channel. But also we did our 
best to stay out of the way and play the game the way that 
they had to have it. 

Rosin: By express channel you did not mean a physical 
device? 


[IBM System/360 family:] Meanwhile, in about 1965, the 
first OS/360 machine was installed. Those became the main 
work force for batch processing. 

So that was the chronology of it all. 

Rosin: I have to interrupt Corby — I graduated from here 


“The number of people trying to use 
the machine was sufficiently 
large that unless 

you had some pull or priority...you 
were faced with a minimum 
of two to four hours of waiting.” 

in 1957, and my first program here was on the [IBM] 650 in 
what was, I think, then called the Computation Center? 

Corbato: Frank Verzuh was one of the people who was 
running a small service group beforehand, and he ran an 
IBM 604 which was a vacuum tube. 50-step, hard-wired 
program machine. He ran a punched-card shop; he ran a 
CPC too. In the Lab for Nuclear Science, they ran an 
LGP-30 series machine. There were all kinds of small ma- 
chines floating around, including [IBM] 650s and later 
[CDC] 1604s, all on the periphery of the center. 


Ross: No, no. no. It was just that we occasionally got faster 
.’.rnaround — a priority type of thing. 

,-i.udience: An analogy is the grocery store. You had a quick 
checkout counter. 

Ross: Yeah. We would adjust what we were doing to try to 
fit that [schedule]. I think we always were straining the 
system — just with the magnitude of what we were doing. 


Audience: Frank Verzuh was the first associate director. 

Corbalo: MIT has always been a diverse place, in kind of an 
anticipation of the minicomputer era. Many small centers 
were successful because they had their own small machines. 
So even though the central machine was the largest, it was 
not unique. 

Another key but minor point — the Whirlwind sped up 
by a factor of 4, so it went from 24 microseconds to 6 
microseconds when they put in the core memory. 


Corbato: Maybe it's worth my interjecting for the moment 
: ' c chronology of the machines, because the way it is coming 
<ui sounds confusing, and we should get it more straightfor- 
ward: 


Whirlwind first came on-line around 1950. The non-Lin- 
coln Lab use ran as a tool for the academic community. 
While it was only limited in use, it ran until (according to my 
recollections) about 1 958 — may be a little later was when it 
actually had to be shut down. 


The Computation Center began in 1957 before Whir 
wind shut down. It started with an IBM 704. At some poir 
v ' as upgraded to an IBM 709 — in 1959 or 1960. 

The IBM 7090 — which of course was the first transistoi 
ized machine in that family. Then that subsequently becam 
an IBM 7094 and that sequence of machines. That machin 
family would run at the Comp Center until about 1973. whe 
they were finally able to turn it off and get rid of it. 


Ross: Yeah, but the throughput only went from 20,000 to 
40,000 instructions. [Laughter.] 

Corbato: My understanding was it really sped up. The other 
thing that I picked up on was that Teager (I believe) built 
all of his own hardware from scratch. He may have been 
influenced by what had been done before, but he designed 
all his typewriter controller stuff himself, and that was all 
after McCarthy wrote a pivotal memo to Morse in 1959. 33 

Lee: Let me quote from John McCarthy again. 25 He’s talk- 
ing about the turnaround time. He says, “This has a very bad 
effect on student theses.” You [Scherr] were talking about 
projects in the classes, but John is talking about theses. 
“When an ambitious student proposes to undertake some- 
thing substantial, his advisor often must say, ‘I do not believe 
you can finish in time for a thesis.’” He continued, “I have 
several students this semester who are in this kind of trou- 
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hlc. I Ik-11 Ik- goes mi lo conclude [hat the solution is clearly 
to have a private computer. Did these restrictions really 
have an impact on the graduate proaram as well as the 
undergraduate program? 

Oirhald: It had an impact on everybody. In fact, it seems 
«i> wit i tile rapid response by personal computers and 
good t, mo-sharing systems, people just do not understand 
low in it was. Its like trying to have a conversation 
through the mail. You can't do it. 

Seherr: I can give you an example. I took a course from 
|V arvm Minsky on timftcial intelligence back in the 1960 or 
I *>1 tune Irame. maybe I %:. We had to do a term project 
and I proposed to write a program that would bid a brid-e 
|hund|. So 1 was going lo take Gorin's book and turn it imo 
a program. Or pan of it anyway — just the opening bids. I 
asked lor and received an hour of computer time for the 


Lee: For the whole project? 

.Seherr: The w hole project. 

Ii was worth a small fortune. Oh yes. it was worth several 
hundred dollars. An hour of computer time in those davs 
was considered a fairchunk and that was good for mnvbe it) 
or -0 shots, and that was typical. People would' do a 
bachelor s or master's thesis and get allocated four or five 
hours. I lull s clocked time on the mainframe, from the time 
j our batch job starts to when it ends. I do not know whether 
Uk\ accounted lor every second, but... 

Kusin: They charged somebody lor ill [ Laughter. | 

Lee: I h, C'orbatdl Were you actually charging people real 
honesi-io-God" green money? 

Corbuto. l * 1al was one the interesting aspects. One of 
the terms ol IBM's donation lor the use of the equipment 
was that we were not to charge for it. It was free all right 
We nevertheless kept books and did the accounting to'trv 
to introduce ft note of moral persuasion, so that we could 
keep people Irorn abusing the amount of time they used and 
Help them recognize how much of the resources 'they were 
using. I he problem was that when we became overloaded 
and we clearly should have been acquiring more machine 
power, we had no money to do it. Nobodv was in the position 
to pay lor anything. That did not ge, sorted out until about 
19fib. when people began to [really) charge for machine 
time. That created the cash flow to acquire machines. 


Ross: In the meantime that's why my projects and Professor 
John Mater s physics project under Michael Barnett, and I 
forget who else, formed the Cooperative Computer Labo- 
ratory at MIT. We had money. They tried to get me to take 
over the whole [IBM] 709 and I said. "No. im not in the 
computer business: I'm not going to run the computer " But 
Slater and Barnett did. and that gave us much better turn- 


around to do our large projects and also look considerable 
pressure otf the regular Comp Center. 

Rosin: That was done with sponsored research funds I 
imagine. 

wJwn '!li L r me explain " here lha ' f'BMI 709 came from. 
[VrmM B 7,!!? CCmer Was Pitching from the 
IBM] 709 to ,|,e (IBM) 7090 in 1962. Michael Barnett was 

Physics n ' S “ a research ass ° ciale for John Slater in the 
Phy .cs Department. He persuaded Slater that there was 
“ ? , ;. r , ^ d,t| onal computation facilities where you could 
cd a hills more li.gh-class service. So he convinced MIT in 
tact, to underwrite the cost to install that machine. 

Audience: Fourth floor. Building 10. 

Corbuto: I forget exactly where. That machine ran in parallel 
with the [IBM] 7090. I, may have been convenient for the 
physicists, but it was also an economic bust. 

c't b , ea ‘ 0arsdv e s 100 much " i,h lhis - 1 "unted 
to offer a slightly different point of view. I had been an 
undergraduate a, MIT - 1 was a graduate student a, the 
University ol Mtchtgan. I did my first vear of graduate work 
m psychology. From our point of view, as people interested 
n computing and interested in doing other things involved 
v th computers, we lelt there were never enough resources. 

I thtnk we have to reflect on how much the advent of 

nature of r '“'’T ° f academic research changing the 
nature ot research in universities. 

For example, in psychology, not a mainstream science or 
tsciplme at MIT but certainly so at manv other institutions 
earn a' PhD h 7"' °' eVe " Smali com P u,ers a student could 
uts AMo?ih 5 Ti faCt0r anal -™ s ™"S d csk calcula- 
te,' on a S 31 t,eCanK a ,hrec - or ^°ur-minu,e 

dol nsveh f C0mpute ;- and psychologists wen, back to 
doing psychology mstead of doing computation 

So there were lots of changes going on at the same time 
Demand was budding up not just because there was not 
enough computer time. but. as you say. Corbv. there were 

They t^iteT* 7' llW ' voodwork wh0 ^ real work that 

they could do. changing their lives with computers. We were 
doing a lot ot good things. 

Corbato: Phil Morse was a pioneer at MIT in terms of 
tying to encourage, feed, and grow the useof computers for 
search in other fields. The universities led the wav because 
than Yh ker 10 aCqi " re neW a PP licati °"S for computers 
' have notl" Th ry genera '' a " d SO we became “‘rente 
resources ™ ” ere ’ m ° re demands “ran there were 

That s why time-sharing sprang out of the university 

hur i °, nm p em 7 Se We WerC the °" es who " ere really 
hurt mg. People were trying to do more programming jobs 

and [fewer] production jobs, [with] more innovations Pro- 
gramming was the thing that was the hardest to do in a 
spcct “ n f es,ed env 'ronment. It seems to me. in retro- 
■P ct. that it was very obvious that time-sharing would be 


40 


IEEE Annuls of the History of Computing. Vol. 14. No. 1. 1992 


first recognized in the university. What was not obvious was 
that industry would be slow in recognizing how important it 

. 1 hat bnngs me to two questions regarding the intro- 
s:-.;..iion of more generally available time-sharing at MIT. 
One would be w ith respect to the Long Range Study Group, 
and the other to outside influences. There has been an 
allusion to Straehey's paper 4 ’ and to things that McCarthy 
was stimulating.- There must have been things going on in 
the computing community in addition to what was going on 
in Lincoln Labs. Is it worthwhile focusing on outside influ- 
ences. or do you want to look at the Long Ran»e Study 

• :ip? 

On the technical side I think the study group not only 
included the studies of MIT's own needs. We went around 
and visited all the major manufacturers, or was that later for 
the Multics project? 

Corbato: Do you remember the date on the report?' I 
thought 1961 maybe. I'll give you my own recollection of the 
chronology. It's a little tricky. In some ways the ideas were 
a ‘ r — [from] people who had used computers back in 
' hirlwind cays when they had direct use of the machine. 
*‘ a d not had any intermediaries or operating systems 
or all that. Whirlwind in a sense was the first personal 
computer. That had not been forgotten by people. I think 
that the person who deserves the most credit for having 
focused on the vision of time-sharing is John McCarthy. I 
do not know quite w hat led John, beyond the frustration of 
the day. John McCarthy wrote a very important memo^ 
where he outlined the idea of trying to develop a time-shar- 
4 ystem. 

• i:n was very prescient — he recognized hardware 
■ us — and to my recollection, he had two key goals: [1J 

One was to make it possible for people to have timelv 
interaction with programs for the small computational 
needs of actually debugging a program in contrast to run- 
ning programs. He thought of time-sharing [as] acting 
against the buffer of larger programs. [2] He also had a 
desire for an individual to be able to use the largest machine 
possible — for an individual who could not have afforded it 
• nimself. So it was a chance to use a very large machine 
problem which was justified by having a very large 
- •nmunity of people using it at the same time. I do not know 
ior sure whether he invented it, although I think he first 
wrote down the vision of how to do it in a fairly precise way. 
h was. in a sense, a .kind of an invention. 

I have read Straehey's paper. Although he was given 
credit for kind of coimagining some of the ideas, when you 
read it carefully. Strachey had in mind the notion of debug- 
ging between jobs or during jobs: it was a much more limited 
' iew ol what we were trying to accomplish: He was trying to 
:0 P ''parallel debugging." Strachey was a modest fellow 
— ;ie did not argue that he had the grand vision, but he 
cv tainly was in novative and deserves some sort of cocredit. 

at McCarthy discovered [the concept] (it s too bad John is 
not here), and I believe McCarthy discovered Straehey's 


work after he had done his work — recognized the similarity 
and acknowledged it was a duality. 

It was interesting [to note] that when Project MAC got 
started a few years later, a number ot people came out of 
the woodwork and said, “Oh. I invented time-sharing,” and 
“Did you read my paper?” and this or that. The problem 

“With the rapid response 
by personal computers and good 
time-sharing systems, people just do 
not understand how bad it was.” 

was that everyone had kind of dreamy visions of people 
interacting with equipment. You can even trace it back to 
Vannevar Bush. 5 who had written a paper in the late forties. 
The thing that John did was to spell out the particulars of 
how you go about accomplishing the notion of having to be 
able to interrupt, [and] the notion of having boundary reg- 
isters. He really began to think it through. He was an evan- 
gelist in part. He was a little cocky about how easy it was to 
do and tried to get IBM to do things, and they kind of 
humored us. We were having a hard time getting off the 
ground because IBM was just humoring us. It was in that 
environment that the Long Range Study Committee was 
created. 

Rosin: Let me interrupt because you've raised some inter- 
esting points. Allan [Seherr]. you said you had McCarthy as 
a freshman. 


Rosin: I want to pick up on this idea of vision — what kind 
of vision did he [McCarthy] give you folks as freshmen? Did 
he talk about computer utilities? 


Seherr A lot of the AI stuff was in there. He talked about 
the chess-playing program project that they were working 
on. It was almost like that course was a recruiting program 
for people working on the chess problem. 

Rosin: I guess I was just trying to find out if John himself 
had something in mind and said. “Gee. this individual use 
of large machines is necessary for chess programs,” for 
example. 


Corbato: John articulated that best in the Greenberger 
book.* 5 But there would be early memos. The early memo, 
in particular, was arguing [that] we ought to try and do 
something right now. The long-range study was set up in part 
to shut John up! He was making enough of a row within the 
administrative circles that they thought [that] we ought to 


I 
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Schem No. 

Rosin: Did he talk about large systems of interacting pro- 
cesses and things like that? The AI visions? 


Seherr Yes. 
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Kosin: \ n( unusual at MIT; 

1 ° r, »iit«:No( unusual! [Laughter 
‘■‘•inuunce decided the on!\ w.t\ i 
have to write another ion 
1 h’ih. That other report' is the nu 
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Lee: If you had been doing the work in the 1950s era. you 
would have done this whole thing in hardware and thought 
about how to build another Whirlwind to do a job. When 
did you move over to saying. "We can do this in software”? 

Corbato: I think from the beginning it was recognized that 
you needed a little hardware help to build the interrupt 
programs — the ability to have clocks, the ability to set 
boundary registries to prevent one program from straying 
into another space. There were a few hardware things that 
were vital. 

Rosin: \ ou said John [McCarthy] saw that in the process 
early. 

Corbato: John was quick to spot the need for alt those things. 
We got IBM’s help in part. They did a certain amount of 
retroengineering on their old machines, but the older ma- 
chines were miserably engineered, because from the point 
°f view of meeting these requirements they had been sloppy. 
If you used a certain sequence of undefined operations on 
an IBM 704 or IBM 709. something would happen. It was 
not what you wanted maybe, or maybe it was. Illegal oper- 
ations were not trapped: individual users could give execu- 
tive operations. It was nightmarish from the point of view of 
trying to share the machine. So those things were hard to 
rectify. It was recognized there was some key hardware [that 
would] help, not a lot. but key. It had to be available early 
enough in the design [cycle] that people could get it in right. 
Then the rest of it was reorganizing [the] software. It was 
never in doubt, I think, that there was a software problem 
to get organized. No one thought of it as just hardware. 

Schem Let me ask a couple of questions. After I got to IBM, 

I was asked a lot about how all this started. One of the 
questions that came up, that 1 never quite got an answer to, 
was about the relationship between CTSS and what was 
going on at Dartmouth with the Basic system — which was 
more or less the same time period — and JOSS at Rand. 
Both systems were originated in the early sixties and were 
time-sharing-like systems. Was there any influence from 
those? 

Corbato: I make reference to those [systems] in my 1962 
paper on CTSS. 1 I did kind of a quick thumbnail survey of 
contemporary systems of the time. My recollection is that 
Dartmouth’s was influenced by our early activity at MIT. 
They saw the idea of time-sharing, but they quickly latched 
onto the idea of a special-purpose system and language — 
that was the influence of [John] Kemenv. Now it’s possible 
that there was some other path to that origin because [John] 
McCarthy had been an assistant professor at Dartmouth. He 
had been recruited by Kemeny to go there, and he was a 
visitor to MIT from Dartmouth. He then finally switched 
over [to MIT], but he obviously still had some ties [to 
Dartmouth]. 

Rosin: You could imagine John visiting up in Hanover and 
trying to spread the same gospel in a very different setting. 


mmm 


Greenbergen But I do not think John's thinking had gelled 
x-: :•-!•; score yet — on time-sharing on interactive terminals. 

In what year? 

Greenbergen 1957. 

Kosin: It was before John was here at MIT. 

Greenbergen The JOSS system was developed at Rand by 
Cliff Shaw as the hardware and software developer. His 
•ion was largely to try to develop a system which was a 
; n’cated calculator to support engineers and physicists. 
,.:Ji like the Dartmouth system, he viewed the goal as 
creating a computing environment that was wholly unto 
itself, and it had a single language. So you put a lot of 
attention into a language that was kind of a sophisticated 
desk calculator. You could program in it. but it was alien to 
everything else that you might be doing. Particularly, you 
could not write a Fortran program because that just was not 
a known language [to that system]. Now whether Shaw got 

• - inspiration from hearing about the time-sharing ideas 

• ere flying around. I do not know. I'm not sure where 
. . got the idea. It started out from the notion of a special- 
purpose system. 

Rosin: Was Dartmouth something like this? 

Scherr: Well, it was a simple system: [fundamentally] they 
invented the Basic language and limited the usage to that. 
That again was later [than CTSS]. 

•nberger: I guess my own recollection of the era was that 
rybodv who began one of these multiple-access systems 
.'.ad been influenced by John or at least had heard about him. 

Ross: I've been really itching to fill in because I’ve just been 
tracking [the discussion] here in my Resume. McCarthy and 
Minsky came [to MIT] essentially at the same time in 1958. 
From 1956. when we in the Servo Lab had success with 
getting our first specially built console attached to the ERA 
■ 103 computer down at Eglin Air Force Base in Florida, our 
• work concentrated on intimate man-machine working 
.--••her. and preceded the sharing of the machine. And so 

• •ere s a whole section about how, if we're going to move our 
work from Whirlwind to the [IBM] 704. “we’ve got to have 
this kind of equipment and it will be extremely desirable to 
have the larger storage capacity and longer word length to 
the [IBM] 704 for use in SLURP” (Servo Lab Utility Rou- 
tine Program — our system in which we did all this experi- 
mental programming). “The SHARE Assembly Program 
' S AP) and the algebraic coding system being developed for 

: :BM] 704 installation by the Comp Center personnel, 

' they never did (it says here), will be more modern and 

• tcxible than the Comprehensive System on Whirlwind and 
so forth. so we really have got to have it. The possibility of 
detailed research into automatic process control and mana- 
gerial business decisions should provide ample justification 
for the active consideration of these techniques as an inte- 


gral part of the MIT Computation Center facility.” This was 
in a memo from me to them. 

Rosin: To whom? To the study group? 

Ross: No. no. this was 1956! Way before. In fact, this was my 

“We all quickly agreed that we wanted 
a time-sharing computer all right, 
but the question of how to go about 
doing it was the part 
that was not unanimous.” 

first memorandum in the Computer Applications Group 
series. “Servomechanisms Laboratory Requirements for 
Computing Facilities. '56-’57.” So it was addressed to my 
laboratory head over at the Comp Center. Our need to have 
continuing man-machine problem-solving capabilities and 
what that would mean to the Comp Center were ringing 
bells on both sides. Here [referring to the Resume] I have 
on November 1. 1956. ”F.J. Corbato called to inquire about 
several of our people giving talks at the seminars and so 
forth.” In January 1958. Peter Elias (then EE Department 
head) suggested to John Ward that I should get together 
with McCarthy. Minsky, and Dick Marcus (who is still here 
at MIT. by the way) because they had just come into RLE 
(Research Lab for Electronics). Here on January 30, 1958, 
“I finally arranged to have lunch with McCarthy, which then 
transferred to Minsky's home in mid-afternoon and we 
talked some more until around 2:30 in the morning.” Sounds 
typical. [Laughter.] 

Anyway, that was the first real ding-a-ling between us 
when they arrived on campus. It was right immediately after 
that, in January 1959. that we had this meeting between 
[Dean] Arden. [John T.. Jr.] Gilmore. McCarthy, Seigel, 
myself, and whoever, to address the questions of using the 
Lincoln Lab [IBM] 709 and the sharing of IBM’s real-time 
package. 

Corbato: But that would have come out of McCarthy’s 
memo. 

Rosin: I sense what you're saying, Corby, but I wonder if 
you’ll agree that John, independent of where the ideas were 
coming from... 

Ross: He’s the one who put them in focus. 

Greenbergen He was the catalyst. 

Ross: Right here [in notes], “McCarthy is calling a series of 
meetings to consider operator and compiler programs for 
the [IBM] 709 which will be transferred to the [IBM] 7090 
which will replace the [IBM] 704.” 
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Rosin: He postered the administration to get this — which 
resulted in the formation of the committee? 

Corhato: I have finally put my finger on what the key issue 
was. You d have to ask the JOSS people whether thev were 
influenced by John. My guess is they were: they'd heard 
about it. But what John was advocating was something that 
was harder than what they were trying to do. He was advo- 
cating a general-purpose system where you could program 
in any language you wanted. That's where Dartmouth and 
all of the others were taking out a slice of the problem but 
not the whole thing. John was very dear on that. Later, when 
we were trying to explain it to people, we would say we were 
trying to create a system where you could write the system 
in itself. That was not true of most of those interactive 
calculator types. 

Greenbergcr: In the late fifties and early sixties there were 
many other thrusts in the direction of on-line multiaccess 
systems, but they were not general purpose. The [AN/FSQ- 
7] defense system was a multiaccess svstem. and so was the 
airline reservation system (SABRE).’ which was started in 
the same time Irame. But these were special-purpose sys- 
tems built to perform specific functions. 

Corhato: One of the arguments we had with IBM engineers 
and executes was that they kept saying. "You do not need 
time-sharing. We are already doing that: we have our airline 
reservation systems." We tried to point out to them that that 
was a transaction system and had nothing to do with gen- 
era I -p u rp» )se program m i ng. 

Rosin: > nu re about to answer a question that I wanted to 
ask. Why was it called the "compatible time-sharing svs- 
icm''? (Spoken in unison — laughter.) What was compati- 
ble? 

Corbato: In retrospect, it was a verv modest problem. 
[Laughter. | 

Scherr: Well, it was important for us who were trving to write 
programs. 

Corhato: That actually is a good lead-in because it ties 
together with Teager's activities. Teager was the one who 
tried to start building a time-sharing system within the con- 
text of the Computation Center. Phil Morse helped him get 
funding, and he tried to get a group together — he had a 
small group. Herb's problem was he was too good a hard- 
ware engineer to want to take things off the shelf. 

Greenbergen Even though he was advocating taking things 
off the shelf! 

Corbato: Yes. but he proceeded to sketch out a system 
where he was going to do everything over. It was going to 
be a total operating system. In this sense, he did nonhink of 
it as general purpose, but you had to do it with his languages. 

He was going to build the hardware for the terminafatta^h- 


ment and the multiplexing of the terminals, and he was even 
going to address the fact that some people are better at 
writing than typing — he was going to allow input bv hand- 
writing analysis. 

Greenbergen He invented what became the Rand Tablet at 
that period in time. Teager Tablet. He maveven have gotten 
a patent out of it — did he? 

Ross: No. as a matter of fact Rand has got it. 

Corbato: Herb tended to be a little close to the vest in terms 
ol the way he managed and operated, and he did not find it 
easy to attract people to work with him. He had this grandi- 
ose vision and maybe a half dozen people trying to work with 
him. It looked like the timetable was going to stretch out a 
long time before anything came out of the door. Further- 
more. he had a fundamental flaw — namelv. that if vou were 
going to use Herb s ultimate system, vou had to abandon 
everything you had done before. 

From The Development of CTSS to 
Project MAC 

Corbato: I started up with just a couple of the kev staff 
people. Marjorie Daggett (who was then Margaret Merwin) 
and Bob Daley. We hammered out a very primitive proto- 

Rosin: W hy don t you give us a date, approximately? 

Corbato: We started thinking about it in the spring of 1961. 

I remember that by the summer of 1961 we were in the heat 
of trying to work out the intricacies of the interrupts. 

Rosin: What was going to be the user interface? 

Corbato: We were going to borrow Teager's engineered 
typewriter interface. We were going to have a few 
Flexo writers initially as the keyboard input. 

Rosin: This was on the [IBM) 7090? 


Corbato: The [IBM) 709. 

Lee: This was using Computation Center funding? 

Corbato: It was all out of the same pot. sure — if vou mean 
computer time. 

Lee: No. no. I’m presuming you had some graduate students 
and other people who needed some salary and other sup- 
port. 

Corbato: No. it was just two staff people. There was no 
external funding. 

Rosin: And the Long Range Study Committee report had 
not yet been released, is that correct also? 
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Corbato: That probably was true. I do not know the chro- 
nology there. But we were acting on the vision we had 
adv internalized. I sketched out what we would, try to 
Marjorie. Daley, and I worked out the hairy details 
: Tying to cope with this kind of poor hardware. By No- 
\ ember 1961 we were able to demonstrate a really crude 
prototype of the system. What we had done was [that] we 
had wedged out 5K words of the user address space and 
inserted a little operating system that was going to manage 
the four typewriters. We did not have any disk storage, so 
we took advantage of the fact that it was a large machine 
and we had a lot of tape drives. We assigned one tape drive 
typewriter. 

• 'In: Weren't you sharing main memory with these peo- 
ple. or were you rolling in and out their programs? 

Corbato: We had to roll in/roll out programs. 

Rosin: One at a time? 

Corbato: On tape. We may possibly have used a drum for 
• ome of that, but... 

..enbergen There was no drum on the [IBM] 709. as I 
recall. 

Corbato: I think you're right. It was pretty miserable. We 
were just trying to get a demonstration system going to 
convince people that it was a good idea. A lot of people did 
not understand what it meant to interact. It was amazing. 

The fact is that this system could operate [effectively] as 
Iona as nobody wanted an "all-the-core-memory” type job 
:.;n under the Fortran ( FAP) monitor system. This system 
'd coexist with that kind of an operating system and 
.ould run jobs. So we could run compatibly, we could run 
while ordinary work was being done on the [IBM] 709. 

Greenbergen The feature that I thought ‘'compatible" 
meant was that you could more or less take a program that 
ran on the normal FMS system and run it under CTSS. It 
meant [compatible] in both senses: it used the programming 
•^tyle. and languages it was using. 

Scherr: A year or so later when Project MAC started. I had 
done an immense amount of programming to do some 
simulation work, and they told me that from now on I’m to 
get all my computer time on the time-sharing system. I said. 
Oh. I m going to have to rewrite all this stuff.” Later I found 
out I did not. because evervthine I had written would more 
or less still run. 


enbergen That was probably the primary meaning of 
compatibility. It was not only compatible with running to- 
gether with the old system, but it meant you did not have to 
start over. So in fact we were able to get versions of Lisp 
running on it. 


Corbato: Let me just get in a few dates. Somewhere in 
November 196 1 we were able to give a seminar and demon- 
stration: that s the date that’s branded in my mind. It was 
only a four-Flexowriter system because it had four [mag- 
netic] tapes, and it would just barely demonstrate. But you 
could have a live dialogue, and it would show that you could 


“You’re about to answer a question 
that I wanted to ask. 

Why was it called the 
‘compatible time-sharing system’? 
What was compatible?” 

get a typewriter to respond. There was a background stream 
going on as well. 

Rosin: This work was going on at the same time as people 
were trying to use this overloaded Computation Center to 
get their work done? 

Corbato: Well, initially we would commandeer the machine 
for periods of maybe a half hour to do a trial run of this 
time-sharing system. Because of [the use of] batch process- 
ing, we could get away with that. [Laughter.] 

Ross: And because you were the in-house crew. [Laughter.] 

Corbato: Oh. there's no question about it; we took advan- 
tage of the fact that we had access. 

Ross: This is the same time that I was feeling so squeezed, 
and I was making deals with IBM to get time outside out of 
their place. [Laughter.] 

Corbato: We could not abuse it. so we had to be prudent as 
to how much time we used. A lot of the time was on 
weekends, which was when we managed to get the hardest 
bugs out. 


Rosin: So, then in November you ran a demonstration — 
but you still were not providing service to anyone. 

Corbato: Absolutely not. It was a demonstration. Then we 
went through a long hiatus where we had to make some 
fairly massive changes. I forget whether we had the memory 
protection properly installed, but in any case it was not used 
and we did not get it sorted out cleanly until we got the 
[IBM] 7090. The [IBM] 7090 hardware arrived in the early 
spring of 1962 and there was then a transitional period. The 
reason I’m so sure of this is that I wrote the paper about it, 
saying that we were running it on [IBM] 7090 hardware, 
thinking surely we would have it running by the time I gave 
the paper. [Laughter.] Well, it was an embarrassment, and 
I still live with that embarrassment. The paper said we were 
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running on the [IBM| 7090. but we in fact had not got it 
running vet.* 

Rosin: Was there any effect by your demonstrations at the 
end of 1961 on the Long Range Study Group? The Long 
Range Study Group report was in the process of emerging 
at that time. There was the study group looking ahead into 
what MIT should launch for the future. [While the future 
-was right there in front of them!] 

Corbato: People were pleased that there were finally exam- 
ples surfacing from [the work]. They did not view it as an 
answer to anybody's problem. 

Rosin: They did not see what you were doing as the first 
step? 

( 'orhato: Absolutely not. 

Ross: 1959, January 12 to 21: "McCarthy is calling a series 
of meetings to consider operator compatible programs for 
the [IBM] 7090 computer which will be a transistorized 
version of the [IBM] 709. which will replace the [IBM] 704. 
We had a meeting yesterday."** So the things were showing 
tip in the Teager report, one or two years later. 

( 'orhato: Let me explain what had happened. We did the 
demo and we had some friends at IBM who worked very 
hard to help make this be a more viable system — Loren 
Bullock, in particular, who was the IBM liaison. Phil Morse 
wax able to get us some money from NSF beeause there were 
three key upgrades we had to have besides switching to the 
[IBM] 7090: getting the proper memory protection and 
trapping the I/O instructions. Those were really critical 
hardware helps, as was getting a real-time clock that could 
interrupt. The first critical upgrade was a disk memory — 1 
Inrget whether it was an IBM 1301 or 1302 — but it was a 
big one for the day. And that got us away from this abso- 
lutely ridiculous restriction that we improvised [assigning] 
one tape unit per terminal. Secondly, the compromise we 
had made by trying to steal 5K of memory from user pro- 
gram space was intolerable. We got IBM to engineer a 
second bank of memory so that we could put our supervisor 
program in it. and at the same time prevent users from 
writing over the supervisor easily. 

The core memory was the second [critical upgrade]. A 
second bank of core memory, and the third key modification 
w-as that we needed something more extensive than a two- 
vear-old home-built typewriter interface channel. 

Ross: Was there a Comp Center [IBM] 7090 before the 
[Project] MAC Center [IBM] 7090? 


[IBM] 709. The switch to the [IBM] 7090 occurred in the 
spring of 1962 at the Comp Center. These changes that I'm 
discussing are with respect to the disk memory and the core 
memory, and the [IBM] 7750 was the big typewriter inter- 
face unit — physically gross, but it did the job logically. 

Greenberger: And a lot more capable than what you were 
supposed to use it for [laughter] — [it was] built to be a 
massive switch, but in the end it was never used for that. 

Corbatd: It was the only thing we could get our hands on 
that could take 32 terminals at once. Today is much differ- 
ent. 

All those upgrades were in place by the spring of 1963. 
Now this was coming together fast enough, and the schedule 
was good enough, that when Bob Fano began to put to- 
gether Project MAC. and his thinking began to gel during 
the Thanksgiving of 1962. it was part of the planning of 
Project MAC. It was possible to consider making CTSS a 
platform for Project MAC. The plan was to get a duplicate 
of the Computation Center [system] for Project MAC — 
and that was ordered approximately at the turn of the year. 
The intent was to use the system during the summer school, 
which was in the summer of 1963. but of course IBM could 
not deliver it quite so fast. So the [Project] MAC machine 
did not show up actually until October [1963]. But we had 
got the system up and functional in the spring of 1963 with 
all of these changes I described, and we were able to use it 
as the first platform in the summer of 1963. 

Lee: I ran across several people who remember the MIT 
summer 1963 event — the CTSS summer school. Were those 
the first people from outside MIT who really got to use this 
system? What was their reaction? 

Corbatd: The intent of the summer session was to make a 
splash. We were absolutely frustrated by the fact that we 
could not get any of the vendors to see a market in this kind 
of a machine. They were viewing it as just a special-purpose 
gadget to amuse some academics. (They were humoring us.) 
They did not see it as affecting the productivity of people in 
trying to get things done. That was a major problem. 


Schern I was at IBM during most of that period as a coop- 
erative education student and later as an employee. That 
was not the case. That may be your impression. 


Corbatd: That was your impression. That was not the case 
from my point of view. 


Schern Why? 


Corbatd: Let me spell it out. I know the chronology pretty 
well. We made the [first] demo in November 1961 on an 

“ Editor's note: A prime example of why historians cannot oven 
always trust the primary sources of information on an event! 

** From Ross's Resume. 


Corbatd: In fact IBM. being a big organization, had every 
thread of thought you could imagine, and we had some 
people working within IBM who were rooting as hard as 
they could and trying like heck to get the company to move 
in our direction more. They succeeded in part, which is why 
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we sot as far as we did. In fact, CTSS would not have been 
possible without a lot of help from IBM. 

. . f r ; As a matter of fact, when I got to IBM after I left 

Project MAC. I discovered that they had been doing a 
time-sharing system in Mohansic, in New York, on the exact 
same hardware that you had at Project MAC. It was called 
TSM (Time-Sharing Monitor), and some guys basically built 
it as a monitor. It had 30 to 40 users, and they were doing 
verv much the same kind of stuff as was going on at Project 
MAC. 

• berger. It was not until much later that people started 

.■ v. it seriously. 

Corbato: Well, in fact, they did not take it seriously until we 
ultimately joined forces with GE [General Electric Com- 
pany]. GE was really not that sophisticated as a computer 
company, but what the IBM people were afraid of was the 
deep-pocket financial help that the GE Company could 
give. 

• .•• enhergen It uas also the fact that you were soon there- 

joined by Bell Telephone Laboratories. 

Corbato: And again we could argue the same thing. 

Let me return to the impact of the summer study. We had 
approximately a 16-active-ports-at-a-time type system. Al- 
though in principle we could run a background stream, I 
think that in those days to make the maximum use of 
time-sharing, we did not have significant background work. 

Ro-in: So how did you run the Comp Center in those days 
, many hours of time-sharing, so many hours batch? 

Corbato: In the Comp Center we had a background stream 
and we worked against that. I [had] jumped ahead to the 
time when we had our own machine. That was, in a sense, a 
heavy compromise because basically we took advantage of 
the fact that the batch processing people could not see the 
impact of interactive users. We got away with it, so to speak. 

The result was that of the several hundred people who 
: ’ ^ived through during the summer, most of them were 
r-.-isuaded — we did not pretend that we had a complete 
system. We did have a general-purpose system. We would 
write arbitrary programs, and since by that time we had 
fairly rapidly sot a set of language choices, we were begin- 
ning to show the potential to be able to use any language. I 
do not remember when we got Lisp, but we certainly had 
MAD.* We had a version of Fortran based on some of your 
own work. Bob [Rosin]. 

People began to say, “Hey, this does seem to be like the 
"• direction. " I think we made a lot of converts, and 
f -”P ; e for the tint time began to break out of this shell that 
had unfortunately descended on the computer industry (or 

* Michigan Aisor.:hm Decoder — a dialect of Algol 58 — imple- 
mented by Bruce W. Arden. Robert M. Graham, and Bernard A. 
Galler. 


the computer users) — namely, that the vendors knew best. 
People began to really seriously think that the architecture 
of machines might be different than it had been before. 

Rosin: I’m curious about the effects inside the institute. You 
said that you were getting away with a lot. I’ve got some 


“We took advantage of the fact that 
the batch processing 
people could not see the impact of 
interactive users. 

We got away with it, so to speak.” 

questions in the back of my mind. What was a significant 
application of CTSS by someone who had no involvement, 
no investment at all in the project? Were there people using 
time-sharing during the day during the spring of 1963, while 
you were getting ready for the summer session? Did people 
actually get work done in that environment? 

Corbato: I do not think we had [any of those] in the pre-sum- 
mer session period. First of all, we did not have it debugged. 
We were conscientious about not taking too much time from 
the other job streams. And I do not think that we ramped 
up enough so that there were any major applications that I 
recall during that period. 

Ross: We were running on the Cooperative Computer Lab 
[IBM] 709 machine. I do not believe we got onto the [IBM] 
7090 until it was the Project MAC [IBM] 7094 in October 
1963, because I have the printout of the first successful run 
of our AED compiler [on that machine], which was within 
two weeks of when they brought the system up. That’s how 
long it took us to sift our way through to get a successful 
compilation on the Project MAC second machine. My im- 
pression was that it was supporting internal beta tests more 
than supporting [real] users. 

Corbato: In one sense the Project MAC situation was one 
extended demonstration — except that it was a self-partici- 
pating demonstration, where users really got to get on the 
machine themselves. Project MAC’S first use of CTSS was 
during the summer session. 

Rosin: You had a wild card naming system** for some files. 
How was that dreamed up? The idea of an interactive editor 
may have been obvious, but where did it come from? The 
idea of logging on and logging off? A runoff capability? 
Electronic mail? 

Greenberger: Too many questions at once. [Laughter.] 

Rosin: I’m trying to get the user’s view of this strange thing. 

**The ability to use a generic indicator for a name, or part of a 
name, usually denoted by *. 
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CorbalorSure. wc knew all of those things were pretty much 
cooked up hy ourselves, but I hesitate to say we invented 
ihem — we tell all ol those ideas were kind of state of the 
art. We were just picking ideas that were floating around and 
which were kind of the obvious thing to do if you were trying 
to put together a system. So the wild card idea — I find it 
hard to believe we invented the wild card because it was kind 
ol a natural — and I must say it’s a very ad hoc design. We 
just sal down and said. "\\ ell. it would be reasonable to do.'* 
and What would be nice?" and "How would you like to see 
ihis organized? * — and that's the way we cooked it up. 

(ireenherger: Some of the editing stuff came, as I recall. 
Irom 1 X-0 in a program called the Expensive Tvpew riter. 

Corbatb: So there were some | prior] prototypes of people 
interacting with machines which I'm sure were in the back 
ol our minds. On CTSS. the first editors were card image 
editors. We did that for a reason. It was because we wanted 
(he metaphor ol a card as a quick and easy communication 
means, so we could explain to people quickly how [the 
system] was used. Once we got rolling, card images were an 
uninteresting artilacl. The next round of editors quickly got 
rid of card images. 


Rosin: That next round of editors — were those done by 
students, by staff, of did they just pop up? 

Corbatb: Well both. Jerry Saltzer. who was then a graduate 
student, did typeset and runoff — a document preparation 
system. He. in turn, borrowed ideas right and left from 
pattern matching and string matching. He did a good engi- 
neering job of pulling together all the things that'were kind 
of recognized [as applicable]. In turn, as soon as people saw 
bow successful (the system | was in doing basically what we 
now call word processing, it was dear that preparing a 
program was just yet another torm ol the word processing. 
Unfortunately, because (MIT] is the sort of place where 
people like to diddle and there are a lot of strong opinions, 
wc soon had more editors than we knew what to'do with. 

Rosin: ///compatibility! [Laughter.] Of course, your file sys- 
tem provided compatibility. You still had a single format to 
your file system. 

Schern Well, hut the different editors had different internal 
formats. 

Corbatb: We made one early decision — in fact. I believe I 
made it — to make the file system neutral to the contents. 
So the file system did not understand w hat it was filing. It 
was quite a deliberate strong boundary, and it meant that 
any language could store material in any format it wanted. 

Ross: Also, any command could be stored as a program in 
any language, because they just had to have a common 
boundary and a common start point. That came from ancient 
Whirlwind. There was alw ays this standard of starting your 


program at register 40 (octal), from which you would jump 
to the actual program start. That technique was just carried 
along with all this history, and so you had a general frame- 
work into which you could put data or be” ready to run 
programs, no matter where they came from — you just 
worried about putting them on the disk. 

Corbatb: That was quite deliberate. We wanted a simple- 
minded system that was basically straightforward to use. and 
the notion ot having a command library — w'ith arguments 
— seemed obvious. 

Schern The file system is kind of interesting. What I wrote 
[in my thesisj is that each track had 466 words, which appar- 
ently was an IBM parameter. The [IBM] 1301 we started 
with had nine million words on it. The files were stored with 
each track being chained to the next, so that when the disk 
was reorganized they put things pretty much in proximity, 
so that it went very fast. As the day. or the week, wore on 
and files were copied over, deleted, or created, the perfor- 
mance ot the system would degrade as the distance between 
the pieces ot the file got larger and larger. As a matter of 
fact, when 1 was doing a performance model a couple of 
years later, it turned out that the parameter measuring how 
well the disk was organized was the single most influential 
one in the simulation. It was almost a knob you could turn 
to get everything to match in terms of performance. 

Greenberger: That's interesting. Because that's, of course, 
the same effect [found in] personal computers. [Laughter.] 

Schern Exactly, the organization is very similar to what the 
PCs do — it was a scheme that we tried verv hard to get away 
fr °m when we went to the [IBM System] 360/370 systems.” 

Lee: C an you identify a time when people began to think of 
this as being a system for communication or a system for 
word processing, as opposed to a system for getting [compu- 
tational] work done? Or did that not happen untiF the Proj- 
ect MAC era? 

Corbatb: Word processing started very early. The Expen- 
sive Typewriter example that was mentioned earlier was 
clearly just that. It was obviously an immediate application 
that people began to use for Saltzer s typeset and runoff. 
They were aimed at exactly that. 

Lee: When did word processing become communication — 
e-mail? 


Corbatb: The communication aspects were a little later — 
one of the things that [Robert] Fano was responsible for. He 
correctly saw that a time-sharing system was more than just 
a set of people using a common resource: it was also a means 
ol communicating and sharing ideas. We began to build [that 
system]. I do not think that was in our initial versions of 
CTSvS. as much as we began to put it in the later evolution 
of it. 
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Rosin: During the Project MAC years? 

Corbatb: Yes. because we kept developing it [CTSS] for 
•••-j! a year or so within the context of Project MAC. 

Rosin: Mv recollection, in looking at the early CTSS manu- 
als. was that it was unusual for a user to be able to refer to 
some other user's files. [You were] logged in and you had 
your user [space]. There was a system for a universal file 
director)' or whatever it was called, and then an individual 
user file directory. Was there a command in the early days 
to he able to refer to a file that was done by. say, Doug? 

• ''err: [There was] a public file area [that] you could copy 
:;gs to and from. 

Corbatb: That's right, we shared through a public file. In 
fact, we came up with a quick solution which was to create 
a public domain. That was the original thinking for libraries, 
handy programs, and the like. And then, when we got into 
the context of operating CTSS as part of Project MAC. we 
continued to develop this [concept]. In fact, as we began to 
ihink about our next time-sharing system, we decided to try 
the ideas on CTSS. and so the second file system devel- 
. for CTSS had the concept of linking. 

Ross: Until then, that public area was the same thing as the 
Compool was. in the programming context, from the old 
SAGE days. In order to go from one user to another, you 
put it in the common area... 

Schern Looking at some of the statistics we took in those 
days, the typeset runoff facility that Jerry Saltzer did was 
1 on the average about once per logon. This data was 
- toward ;ne end of 1964 during about a four-month 
i".:sOd.* so it was after the system had matured a little bit. 
Basically, what was going on was that typeset and runoff 
accounted for about 1 percent of commands issued and 
logon and logoff were about 1.5 percent. 

Typeset was a mark-up language — when you used 
typeset you put in a document mark-up language to do 
things like centering, headings, etc. 

•-•ivjn: What was that editor called? 

• .rver.bergen There were two versions — eci and edm. 

Scherr: ed would [constitute] 4.5 percent of the commands. 

he edit, which was the card image editor, was 4 percent. So 
'I was still being used after the shift that had already started 
to occur toward this more free-form editor. 

Rosin: Was there a mail command? 

rr : No. there was no mail command. 

Ross. But you could find out who was on the system! 

i>cc excerpts :ron Scherr ‘s report in the next issue. 


Corbatb: No. no. no. no. But we were working in that 
direction, and there were a lot of the pre-Multics ideas 
during the last versions of CTSS. We had the aspiration of 
going in those directions, but it was a tough environment to 
work in. As we began to wind down, we put our effort into 
trying to put all the things we wished we had into Multics. 


“A time-sharing system was more than 
just a set of people using 
a common resource; it was also a 
means of communicating 
and sharing ideas.” 


Rosin: A little bit about the terminal equipment. Two kinds 
of questions come to mind. (1) with respect to the kinds of 
equipment used and how that evolved in the early days, and 
(2) the first system for dial-up use of CTSS. during those 
early days? 

Corbalo: OK. good point. 

The terminal system was very unsatisfactory. Everything 
was ugly in one way or another. Flexowriters were noisy, 
unreliable, and slow. The IBM equipment that we were able 
to get them to adapt always seemed to be designed for some 
other purpose. So even though they had Selectric typewriter 
elements in them, we had trouble getting type balls that had 
reasonable characters. We were also fighting another fight 
at the time, which was to get people to admit that upper- and 
lowercase were part of the computer vocabulary! We kept 
insisting that we wanted both. That was tough. Most IBM 
keypunches did not allow both, and Teletype did not allow 
both. 


Scherr: If IBM and AT&T did not allow them, they must 
not be needed. [Laughter.] 


Corbatb: That's right. Even in the early manuscripts. I think 
there were a dozen terminals that we managed to test — 
almost all of them [were] unsatisfactory. Even the Teletype 
model 37 [which] was an upper- and lowercase unit (which 
was later followed by the 33. which was a cheaper version) 
was pretty clunky and noisy with slow response. 

Rosin: Slow response, five characters per second? Ulti- 
mately IBM came out with some pretty decent Selectric 
units which were capable of being a good terminal. 

Lee: The [IBM] 2741? 

Ross: The [IBM] 1050 was a heck of a step up from the 
Teletype. That was the big thing around Project MAC in 
those days! Who is going to get a 1050? 
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Time-Sharing at MIT 



Rosin: What about off-site systems? I recall some early 
anecdotes about people using CTSS from home. 

Corhutb: The next thing we did was we got the late Carlton 
Tucker to assign us some [telephone] lines, and we got 
AT&T to cooperate in giving us modems. 

Rosin: Lines on the MIT campus? 

Corbato: On the campus PBX. People could have them in 
their office, and they could dial up to CTSS. In fact, when 
we got two CTSSs on campus, it was convenient because you 
could then dial the one you needed or were trying to use at 
the moment. 

Rnss: Or the one that was not out. But before the dial-up 
came. I used to tweak Corby and Fano while they were 
setting all this stuff up with Tucker and deciding how to go 
about it. I had my own Computer-Aided Design Project 
money, so as soon as I realized that was going on. I moved 
I to CTSS]. I had not been able to program all the years we 
were getting off the Whirlwind and onto IBM. I never 
learned how to turnon a keypunch, and I had never touched 
an IBM machine before. 1 did some T.Y-0 programming — 
that's all. So I saw my chance to get back in and show my 
programmers what I had been trying to get them to do. So I 
just picked up the phone and called Teletype (which was a 
separate division of AT&T) and said. ' Let's pul one in!" 

I hey spent three months getting a line out to my home in 
Lexington. It was a great huge box in the basement. Al- 
though American television ignored it. when the MIT press 
oil ice said this was the first one [in a home]. Canadian 
Broadcasting Corporation [CBC] and British Broadcasting 
Corporation |BBC| sent film crews [to my home] in the 
spring of 1964 or 1965. So that was the first Teletype at a 
home, connected to a computer. It was a direct line though: 

I did not dial at all. 

Rosin: Was it hardwired to the machine or hardwired to the 
switchboard? 

Ross: Hardwired all the wav to the computer. I had it there 
for two to three years, and once it was up it never made an 
error. 

Corbato: I would say it had a couple of effects. It opened up 
people's eyes to the fact that distance did not need to be a 
factor. Of course, hard lines were feasible, but the dial-up 
was [the next logical step], and that led some people to try 
some real gutsy demos which came in from Europe and 
[elsewhere]. They discovered [that] they had nightmares 
with the telecommunications [in] trying to pull off demos 
through all those foreign switchboards. It was really wild. 

So there are all kinds of stories around that. There was a 
fellow by the name of Joe Wegstein.* who used to work at 
the Bureau of Standards. He was visiting one day. and I was 
kind of showing off where we were. I walked up to a pool 

* Joseph Wegstein. Chairman of the CODAS YL Short Range 
Committee. — staff member. National Bureau of Standards (now 
NIST), see Annals. Vol. 7. No. 4. 


room where we had a bunch of typewriters. I dialed up a 
number, and I accidentally dialed the Project MAC ma- 
chine. 1 meant to dial the one downstairs in the Computation 
Center. It was not until the login masthead came up that I 
realized the mistake and said. “Whoops. I made a mistake. 
I m not dialed into the [Project] MAC we were just looking 
at: I'm dialed into another one." He said. “Where is it?” I 
said. "It's over there." 1 pointed across the street to the other 
building and he looked at me somewhat incredulously — I 
don't think he believed me. Nowadays that's taken for 
granted, but in those days that was really [surprising]. 

Schern l remember being in the [Project] MAC room one 
night. In those days whenever anybody logged on or off. the 
[activity] was printed on the big line printer that was part of 
the [IBM] 7090. Somebody from England had dialed in and 
was clunking away at five characters per second with [Proj- 
ect] MAC... I forget who it was. 

Lee: Maurice Wilkes? 


Schern It was Wilkes, as a matter of fact! We knew who it 
was because it said “Wilkes" and somebody said. "Oh. that’s 
the guy from England." 

Rosin: What year was that? 

Schern 1964 or 1965 or thereabouts. 

Rosin: So things were really starting to happen after that 
summer session? 

Schern I was a graduate student in those days, and I had just 
got my master's degree. 1 had spent a year as a teaching 
assistant and most of my career learning how to do logic 
design. I had decided that there was no future in trying to 
get a PhD by building hardware, because it was so hard to 
get tunding to build things. So I decided I'd do some pro- 
gramming for my PhD work, and what I had chosen was 
logic simulation. I had written some programs to do that. I 
had been an IBM co-op since my sophomore year (which 
was 1960). and by the summer of 1963 I was a summer 
employee of IBM in the Cambridge Scientific Center, which 
in those days was up by Harvard Square. I spent that summer 
writing software to do logic simulation. 

So now I came back to school in September of 1963 after 
the summer session. Herb Teager was my thesis supervisor. 
He said. “Everybody who's doing anything with computers 
is in Project MAC. That's where the research money is, so 
that's where we’re going." My reaction was. “OK. as long as 
there is money and as long as I get computer time.” Also, 
the question was. “Do I have to convert my programs 
[again]?" I had completed almost all my course work for a 
PhD. so the next job was to get my topic picked. The 
committee I had was [Robert M.] Fano and Ron Howard, 
who was the operations research guy. and Dave Liu. 

Herb tried to talk me in to doing modeling of time-sharing 
systems — performance modeling. 1 alwavs thought that 
what he really wanted me to show [was] how terribly ineffi- 
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cient. slow, and unwieldy this whole thing was. I took some 
measurements of reality to compare [with] the model. I 
<• ':,;d. “What is being done on CTSS to measure its perfor- 
:.;ce. its efficiency, its characteristics, etc.?" As it turned 
. ml. there really was not any. Tom Hastings had done some 
verv earlv. very good work. But that was about it. It was not 
even close to what I thought was needed. Here I was, 
probably early in 1964. more or less committed to a course 
of research that required me to either discover measure- 
ments wherever they were or make them myself. 


Corbato: That's a very interesting... I'm glad you brought 
- :- ,t up. There was a difference of viewpoint between 
•Laser's thrust and ours, which in hindsight is easy to see. 
Herb was trying to engineer it from the ground up. He 
wanted to do it just right; he wanted to see the system 
running efficiently: he wanted to see good user resources: 
and, if he could not get it that way, he was willing to wait. 
We were trying desperately to get a prototype going to 
get people's attention. So Herb's project ultimately never 
came off because it kept disappearing into the future, and 
ours would shift in a very ad hoc fashion and [a] “let’s get 
: re going" [way]. Clearly it became the thing that we built 
a P°n. 

Schern And it gave you something to measure. [Laughter.] 

Corbato: We would try to [develop a] prototype because we 
saw a major watershed in the way people looked at comput- 
ers in terms of whether they could interact in real time or 
not. So it was important to get a machine that did that — 
whereas Herb was still focused on trying to justify [the fact] 
'hat he was making good use of all the resources. 


Rosin: There’s an interesting contrast between different 
people’s views of reality in what you just said. You said 
resources. You see, if what you're trying to do is optimize 
technical resources (physical resources), Herb’s point of 
view was exactly right. If you try to optimize the use of 
human resources, then the point of view you were taking 
was a lot closer to reality. 

Lee: This ad hoc development — it sounds like it was almost 
independent of the [study] committees! 

Ross: As you debate the different views between Teager and 
Corbato and Fano, I would like you to realize that you’re 
hearing from two insiders with respect to us outsider groups. 
The fact is that availability of a Project MAC [IBM] 7090 
[using] CTSS. with all this eagerness to invite outside groups to 
make it fly — make it useful and so forth — had quite an impact 
on us. We were on the crack: we were neither inside nor outside, 
but were not the proper kind of outside either, because we were 
providing a service to other people. That was our mandate as 
the Computer-Aided Design Project I always say, “You can’t 
design an interface from just one side." 

Corbato: In terms of what influenced us — it was basically 
the thinking that got caught up in the small Long Range 
Study report. That was clearly what was on my mind, and 
I was the leader of the CTSS development. It reflected 
completely an attempt to implement those ideas using 
contemporary tools. I never claimed to be more than a 
person who brought into development the ideas we had 
been all talking about together. So I was trying to [de- 
velop a] prototype, but I was not working on an indepen- 
dent theme. My inspiration was the same inspiration as 
the Long Range Study report. ■ 
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Research-oriented time-sharing systems 

(Adapted with permission from the “Time-Sharing System Scorecard” prepared by Computer Research Corp. in fall 1967.) 


Bell Telephone 
Laboratories, 1 
Munay Hill. N J. 

Bolt Beranek and 
Newman. Inc.. 
Cambridge, Mass. 


| CSIRO. Canberra 
I City. Australia 


Status Type Computers) Languages 


D (1/68) G GE 645* 


Main Secondary No. 

Storage Storage Use 

256K DK (40M wds.) lOtT 

DR (4M wds.) 

Tape loop 
(100M wds.) 

24K (4K) DR (128K wds.) 64 

, DR (2 units. 2SM 
• v?! wck.each) 

MT (2 units) 

32K (2K) DR (2 units, 5M 7 

wds. each unit) 
DK(12JMwds.) 

MT (8) 


Remarks . v v.;.--.;..-". 


Highly interactive system 
for research and 
production computing. 

Medical information and 
communications system for 
hospitals. Also used for 
computational and data 
management facility. 


• Dartmouth College, 
i Kiewil Computation 
Center. Hanover. 


Edinburgh Univ.. 
Dept, of Machine 
Intelligence and 
Perception. 
Edinburgh. Scotland 
! General Electric. 

• Research & 

■ Schenectady. 

■ Lawrence Radiation 
I Laboratory. Univ. of 
I California. 

I Livermore. Calif. 


Lincoln Laboratory 
(MIT). Lexington. 
Mass. 


Lockheed Palo Alto 
Research 

Laboratories. Palo 
Alto. Calif. 


. DcpLof 
■ hiciinul Eng . 
Cambridge. Mass. 
National Bureau of 
Standards. 
Washington. DC. 
Northern Electric 
Co.. Ltd. Research 
4 Development 
Laboratories 
Ottawa. Ontario. 
Canada 

Ohio State Univ . 

' ftimhtis. Ohio 


Petkin Elmer Corn., 

Norwalk. Conn. 


Partial G 
0(7/67) 
Complete 
D (6/68) 


GE 635 BASIC. . . 

Datanet-30 ALGOL-35, 

(4) (1/68), 

FORTRAN 

(1/68) 

Elliot 4120 POP-2 


PDP-6 (2) 
CDC7600 
CDC 6600 (3) 
CDC3600 
IBM 7030 
IBM 7094 (2) 


TT-33 (55) 

64K (24K) 

DR (768K wds.) 
DK (2 units, 4M 
wds.) 

MT (6 units) 

200 

Datanet-30s have 16K core 
memory each. Educational 
and research use. 

IT (20) 

32K (16K) 


8 

POP-2 language suitable for 
list processing and 
numerical computation 
using FORTRAN type 
statements. 

TT (45) 

CRT (3) 

16K (6K) 

DK (20M char.) 
MT (6 units) 

21 (TT) 

3 (CRT) 

Uses include scientific 
programming, data 
acquisition from 
experiments, system 
programming development 

TT (200) 
PLT(10) 

256 K 4 
wds. 

DK (8x10* bits) 
DC (3 2 x 10* 
bits) 

Photo-digital 
store (1 x 10 IJ 
bits) 


Use is mostly scientific 
computation. 

TV (5) 

CRT (4) 

Rand Tablet 
PDP-338 
Remote 
terminal 

105K 

DR (20M wds.) 

6 

System features fast 
response rime for on-line 
graphical communication. 

IBM 2741 
(30) 

128K 

DR(lMwds.) 

DK (56M wds.) 

20 

Establishment of a large 
computational facility for 
scientific and engineering 
research. 

IBM 1050 
(36) 

IBM 2200 
(6) 

64K (20K) 

DK (6.45M char.) 

42 

System named RAX, 
developed from earlier 

360/40 system, used mostly 
for engineering 

IBM 2260 
(4) 

Sanders 720 

64K bytes 

DK (2 units. 

275M bytes 
each) 

DC (418M bytes) 
MT (1 dual) 

12 

System named LACON1Q. 
Information retrieval and 
updating research. 

IBM 2741 
(5) 

128K 

bytes 

DK (2) 

10 

System named ICES. Uses 
include engineering, 
science, management. 

TY(5) 

12K (8K) 

DR (88K wds.) 7 

MT (6 units)' 

5 

Experimental time-sharing 
system for student use in 
thesis and research projects. 

TT-33. 35 (4) 
CRT 

16K(6K) 

DK(1M wds.) 

MT (4 units) 

6 

Uses include research in 
the design of on-line ' 
systems and terminals. 

TT (70) 
8130(4) 

82K 

6SK 

(4K) 

DK (12 units, 

852M char, 
each) 

MT (10 units) 

35 

Scientific and business use. 

IBM 2741 
(20) 

IBM 2260 
. (8) 

512K '.■■f 
bytes 
1024K 
bytes 

DR (1 unit) 

DK (1 unit) 

14 

. J&VGVU'i 'JC thl J 

TT-33, 35 

IBM 2741 

IBM 1050 

32K v , 

16K 

(22K) 

DK (67M char. 
1/68) 

MT (4 units) 

DR (4 units. 8M 
char.) 

16 

Uses include lens design, 
circuit analysis, scientific 
engineering, and research. 


(Table continued on the following page) 
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(“Research-oriented time-sharing systems” continued) 


Organization 


Status Type Computer^) Languages Terminals Main Secondary 


No. of Remarks 
Users 


TT-3S (54) 64K (32K) DK(36Mwds.) 30 


Project MAC is an MIT-2 
research program ' “S* JS 
sponsored by the Advanced ■ 
Research Projects Agency ' 
(ARPA). DOD, undera -£*- 
contract with the Office of 5 r 
Naval Research. . 

Initial limited system ' — . 
operation by early 1968 \ - 

with continued , *33 

development thereafter. 
System named PTSS. 


Phase 1. MIT, 
Cambridge, Mass. 


IBM 1050 
(56) 

TLX (1) 
CRT (2) 


DR (.5M wds.) 
MT (12 units) 


Project MAC. 
Phase 2, MIT, 
Cambridge, Mass. 


D (1/68) G 


TT-37 
IBM 2741 


ALGOU n 
COBOL 
FORTRAN IV. 
pl n 


DK (40M wds.) 100 
DR (4M wds.) 

MT (8 units) 


Purdue Univ., 
Computer Science 
Dept.. Lafayette, Ind. 


0(9/67) G IBM 7094 


File 

generation. 

TEXT-90 

(12/67). 

FORTRAN 


TT-33 (2) 32K (16K) DK(9Mwds.) 

IBM 1052 MT (9 units) 


Rand Corp.. Santa 0(11/65) G PDP-6 
Monica. Calif. 


DK (6M wds.) 
DR (1M wds.) 


Interpretive system with . 
compact conversational 
language for small 
numerical problems. * 
An IBM 360/67 will be 
operational in 1968. j 


Stanford Univ., 
Stanford. Calif. 


0(8/64) G PDP-1 


Assembly 

language 


PhilcoCRT 
TT-33. 35 


DR (131K wds.) 
DK 

MT (2 units) 

DR (5 units. 

139K wds. each) 
DK (1 unit, 4M 
wch.) u 

MT (12 units) 

DR (48K wds.) 
MT (2 units) 


System Development 0(1/64) G 
Corp.. Santa Monica. 

Calif. 


AN/FSQ-32 

PDP-1 


65K (47K) 
16K 
buffer 


TINT. IPL-TS. 
JOVIAL. USP 


Oriented to command andr 
control experimentation j 
and other general uses. 


TRW Systems 
Group. Redondo 
Beach. Calif. 


0(1/65) S 


Bunker-Ramo 

340 


Culler-Fried 
system for 
mathematical 


Highly flexible system for j 
on-line manipulation. ^ 
specification, and execution - 


of mathematical and \ 

symbolic operations with 
graphical display of results^ ; 
Jointly financed by UCLA .if* 
and IB M . the system v Vy ■ 
services UCLA and 88 ;,vy' 
other California schools. 


UCLA Western 
Data Processing 
Center. Los Angeles. 
Calif. 

United States 
Military Academy. 
West Point. N.Y. 
Univ. of California. 


0(11/64) G IBM 7740 u 

IBM 7040/7094 


0(12/65) G GE22S(3) CADETRAN 14 1T(15) 
Datanet-30 


DK(18Mchar.) 15 
MT (2 units) 


0(1/66) G IBM 1410 
IBM 1440 


JOSSI* 
Course writer 


DK 

MT (5 units) 


Uses include 

computer-assisted f'fri 
instruction and the 1 V/I 
admiiustraoon of student 
enrollment. . 

Instruction, administration;] 
and research. , 


Univ. of California. D(l/68) G IBM 360/50 
Irvine 


IBM 2741 512K 

(28) bytes 

IBM 2260 (8K bytes) 

(3) 

TT-33 (8) ’ 48 K 

TT-35 (8) (38K) 

CRT (2) , 

Dataphone 

(6) 


DK (12 units. 
7.25M bytes 
each) 

MT (4 units) 

DR (1.3M wds.) 
MT (2 units) 

DK (144M wds.) 


Features hardware address ' 
mapping. The SDS 940 . . >■* 
system is based on the ' • / 
results of this 

ARPA-sponsored project, .v.' 

Extension of the 
Culler-Fried system now'?» 
operating on the RW400tsE 
The 360/50 system has . Tl 
simultaneous background,.^ 
processing. 

Experimental time -sh aring: 
system for general -j _ f 
university research. ■ 

Uses mdude education inc*^; 
varied research program*!*/ 
diverse fields. - 


Univ. of California. 
Project GENIE. 
Berkeley. Calif. 


0(4/65) G SDS 930 FORTRAN II. 

ALCOU LISP. 
SNOBOU 
CAU DDT. 
QED.ARPAS. 
QSPL 

D(l/67) G IBM 360/50 Culler-Fried 

system, 
FORTRAN IV 


Univ. of California, 
Santa Barbara 


20 consoles 14 64K 

Rand tablet 
IBM 1050 
(3) 


4 DK (1.8M wds.) 16 
DR (1M wds.) 

Core (.5M wds.) 


Univ. of Illinois, 
Urbana 


TT-33. 35 (8) 8K(6K) DK(10Mwds.) 7 

CRT DR (64K wds.) 


Univ. of 0(9/67) G CDC3600 BASIC TT-33. 35 32K(8K) DR (2 units. 2M 32 1 

Massachusetts. PDP-8/680 SNOBOU char, each) 

Amherst COCO. DK (2 units. 8M 

SMALU char, each) 

FORTRAN IV MT (4 units) 

Univ. of 0(6/65) G IBM70W FORTRAN. TT-35 (4) 32K(24K) DK 6 

Pennsylvania. PDP-8 MULTI-LANO. BR(2) MT (6 units) 

Philadelphia map, 

ALCOU USP. 

SNOBOL 

Univ. of Pittsburgh. 0(3/66) G IBM 360/50 ALCOU PIU 5 IBM 1050 128K DK (2 units. 24 

Computer Center. FORTRAN rv. (3) bytes 7.5M bytes) 

Pittsburgh. Pa. PL/l(l/68), IBM 2741 1M bytes 

Assembler (20) LCS 

(32K 
bytes) 

Univ. of Utah. Salt D (12/67) G Univac 1108 fortran V. TT-35 (20) 131K DR (6 units. 20 

Lake City TRAC (65K) l-5Mwds.) 

COBOU MT (8 units) 

ALGOL FastRand II 
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’ 'otes 


1. Development in cooperation with Project 
MAC. MIT. 

2. Multiple-processor time-sharing system. 

3. Developed with the Massachusetts General 
Hospital under contract from the National 
Institutes of Health. 

4. Based on an earlier five-station PDP-1 sys- 
tem operational 9/62. 

5. Based on the Rand JOSS language. 

rhe 256K core storage applies only to the 
PDP-6s. 


7. To be replaced by a larger model early in 
1968. 

8. Units have been installed but are not oper- 
ational. 

9. Initially time-shared in 1961 at the MIT 
Computation Center. 

10. Other languages include FAP. SUP. COGO. 
SNOBOU STRESS. GPSS, COMTT. OPL-I. and 
OPS-3. 

11. Most Project MAC Phase 1 languages will 
be implemented later. 


13. Additional unit available in January 1968. 

14. Each console consists of two keyboards and 

a storage tube display. .. 

15. System currently utilizes five computers in ; 
addition to the control IBM 7740. 

16. CADETRAN is an extended teaching dialect 
of FORTRAN. 

17. 64 with added communications ports. 


Characteristics listed in charts 


Status 

O Operational system; number in parentheses is the approximate date that the system went on the air. 
D System under development; anticipated date that operations will begin. 


G General purpose 

S Special purpose 

Computer 

Manufacturer’s name and number of central computers in system. 

Languages 

Basic languages available on the system at present. 

Terminals 

Type of terminal equipment available; number of such terminals in parentheses. 

TT Teletype; number following denotes terminals and model number. 

TY Typewriter 

TLX Telex console 

CRT Cathode-ray tube display 

BR Bunker-Ramo Series 200 display consoles 

IBM IBM 1050, 2741 keyboard consoles; IBM 2250, 2260 

Philco Philco display consoles 

PLT Plotter 

Main Storage 

First number denotes total core storage in words on the system; second number in parentheses, if given, i 
maximum core storage available to an individual user. 

Secondary Storage 

DR Magnetic drum 
DK Disk file 

DC Data cell 

MT Magnetic tape 
Core Bulk core 

CF Random-access card file (K = 1024, M = 1,000,000 words per unit). 

No. of Users V * . 

Maximum numbers of users who can operate simultaneously at any given time. 
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Commercial time-sharing systems 

Users could purchase remote, on-line, and interactive computer services from the organizations listed below. ( Adapted w 
permission from the ■'Time-Sharing System Scorecard" prepared by Computer Research Corp. in fall 1967.) 


Organization 

Computer 

Conversational 

Languages 

Terminals 

Number of 
Users* 

Minimum 
Charge per 
Month 

Average 
Charge per 
Terminal 
Hour 

Charge per 
Minute of 
CPU Time 

Disk h 

Storage per ? | 
Customerf t 

— 

Allen-Babcock 

Computing. Inc.. Palo 

Alto. Calif. 

IBM 360150' 

PUl (on-line subset) 

IBM 2741 
TT-33. 35. 37 
Friden7100 
IBM 1050 

90 

S385.00 

None 

35-310 2 


Applied Logic Corp.. 
Princeton. NJ. 

DEC PDP-6, 

PDP-10 

(12/67) 1 

FORTRAN IV. DDT. 

JOSS. MACRO- 10. 

Compact COBOL. 
USP.SNOBOL-6 

TT-33. 35 

CRT 

30* 

N0 ” 

$5.00 

$6.00 

Bolt Beranek and 

Newman. Inc.. 

Cambridge. Mass’ 

PDP-7/8 

TELCOMP 

TT-33 


None 

$12.50 

None 


CEIR. Inc.. Arlington. 

Va. 

GE235 

Datanet-30 

BASIC. ALGOL 

TT-33. 35 

40 

S250.00 

$6.00 

No,. 

I20K i : 

Computer Sharing. Inc.. 
Bala Cvnwyd. Pa. 

SDS 940 

CAL. ARP AS. BASIC 
DDT. FORTRAN IV. 
FORTRAN II 

TT-33. 35 

32 

None 

$30’ 

None 

60K* 

•’ fC ’» 

Corn-Share. Inc.. Ann 
Arbor, Mich. 

SDS940 

BASIC CAL 

FORTRAN IV. 

SNOBOU TAP. DDT. 
FORTRAN II 

TT-33. 35 

64 

$100.00 

$10-320 

$2.50 

0» 

Dial-Data. Inc.. Newton. 
Mass. 

SDS 940 

CAL. DDT. OED. 
FORTRAN II. 

BASIC ALGOL 
FORTRAN IV. 

SNOBOL ARP AS 

TT-33. 35 

32 

S 100.00 

$13.50 

$3.00 

60K+ . ' L ’ 2 

| 

General Electric Co.. 
Information Service 

Dept.. Bethcsda. Md.’ 

GE 235 
Datanct-30 

BASIC ALGOL 
FORTRAN 

TT-33. 35 

PLT 

40 

$100.00 

$10.00 

$2.40 

- -M 

m 

International Business 
Machines. New York. 

N.Y.’ 

IBM 7044 

QUICKTRAN 

IBM 1050 

IBM 2741 

80 

$125.00 

$12J0 ,# 


"■ ■ 

;. i /-' 

Intinco Limited. London. 
England 

Keydata Corp. (Adams 
Assoc.). Cambridge. 

Mass. 

Univac 418 (2) 

Univac491 

Stockbrokers’ 

Language 

KOP III 

TT-33 (60) 

TT-28 

60 

200 

- 

■■ 

- 

'H 

Pillsbury Occidental 

Co.. 1 ’ Raleigh. N.C. 

GE 265 

ALGOL BASIC 
FORTRAN 

TT-33. 35 

PLT. CRT 

40 

$108 JO 

$10.00 

$3.00 

o* ■ .-~tJ 

Realtime Systems. Inc., 
New York.N.Y. 

B-5500 

FORTRAN IV. 

COBOL ALGOL 

IT. TLX. 
TWX.CRT 

15 

$500.00 

$15.00 

$8.35 

°* ^§1 

Tymshare.Inc-.Los 

Altos. Calif. 

SDS 940 

CAL BASIC OED. 

DDT. FORTRAN IV. 
ARP AS. ALGOL 

TT-33. 35 

PLT 

60 

$80.00 or 
$390.00 

$13-316 

None 

ftOK* 

VIP Systems Corp.. 
Washington. D.C. 

IBM 1440 

IBM Administrative 
Terminal System 

IBM 2741 

40 , 

$375.00 

$7 JO 

None 

iook^M 

• In all cases, the number of simultaneous users can be increased by the addition of equipment or by duplicating the computer system, 
t Number denotes amount allocated in characters or bytes: ♦ indicates more available at extra charge. 
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1. Special operation codes for efficient conver- 
sational interaction added. 

2. Dependent on amount of core used. 

3. This new system will be in operation early 
in 1968. 

4. Will be increased to 40 in late January. 

5. Systems located in Cambridge. Mass.; East 
Orange, N.J.: and London, England. 


6. Cambridge and East Orange handle 32; 
London handles 16. 

7. For the first 20 hours; $25 per hour thereaf- 


8. Service available from offices located in 33 
major metropolitan areas. 

9. Other systems in Chicago. Cleveland, Phil- 
adelphia, Los Angeles, and Toronto. 


10. For the first five hours; $11 for hours, 
through 75, $9 per hour thereafter, i 

11. A charge of approximately $5,000 pef.yi 
plus a usage charge of $.05 per inquiry! 

12. For accounting and manage ment.-' as 
Charges on the basis of message transit 
sions. processor time, and storage usecfc. 

13. Trade name Call- A-Computer. 
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The emphasis differed in each case. CTSS was oriented 
toward a general-purpose service offered by a central com- 
pl , t : na service. The MIT PDP-1 system was organized to 
. vw each user direct control of I/O devices in native ma- 
ci-ine languages, but with protection from other users, so 
that each user was presented with a virtual machine capable 
of running arbitrary programs. The BBN PDP-1 system was 
oriented toward an environment for interactive program 
development which included the use of a high-performance 
graphical display. The Dartmouth system focused on intro- 
ducing computing to nonprofessionals with the constrained 
but easy-to-leam BASIC language; the JOSS system fo- 
cused on a carefully human engineered computational pro- 
: . -ming interface; and the developers of the AN/FSQ-32 
svsicm were interested in similar objectives to those of 
CTSS, but in the context of developing and maintaining 
large programs for military applications. 

These time-sharing systems, while among the earliest and 
more significant, were not the only ones developed in the 
1960s. Rather they display some of the variety of objectives 
and directions taken. With hardware obsolescence, none of 
the systems has survived, except for the BASIC system, 
which, with changes of hardware, continues to evolve as the 
• computing facility of Dartmouth College. Neverthe- 
L.--. me early systems have had direct influence on almost 
all the current time-sharing systems in use, frequently by the 
students of one system becoming the designers and im- 
plementers of the next. 

By the mid-1960s, time-sharing systems, and especially 
those of MIT’s Project MAC and of Dartmouth College, had 
attracted considerable attention among computer users, 


managers, and manufacturers. The obvious impact of time- 
sharing systems forced these different groups to reevaluate 
their roles and the desired modes of computer use. More- 
over, development of extensive new time-sharing systems 
had begun. Among the more notable plans were those for 
the Multics system (by MIT’s Project MAC, the Bell Tele- 
phone Laboratories, and the General Electric Company) 
and the TSS system (by IBM for the IBM 360/67), which 
were especially comprehensive in their goals. Indeed, this 
very comprehensiveness led to underestimations of the scale 
of the software engineering required. The Multics system, 
eventually marketed by Honeywell (which had acquired the 
GE Computer Department), took several years longer to 
develop than initially anticipated. The TSS system, imple- 
mented by a much larger group, was not as delayed as 
Multics, but had disappointing performance and human 
interfaces when first delivered. Despite these warning signs 
of engineering complexity, by the end of the decade, dozens 
of time-sharing system implementations were being devel- 
oped both by ambitious users and by major manufacturers, 
and time-sharing was well recognized as a significant mode 
of computer interaction. 

T he series of “Time-Sharing System Scorecards” pub- 
lished from 1965 to 1967 by the Computer Research 
Corp. chronicles the development of time-sharing systems 
in research organizations (universities and laboratories) and 
the expectations for commercial offerings. The last of these 
scorecards (reproduced here) shows a stage of development 
when time-sharing was still new enough to be a research 
effort and not quite mature enough to be commonplace. ■ 
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A Note on the Multics Command Language 

A. W. COLIJN 

Department of Computer Science, The University of Calgary, Calgary, Alberta, Canada T2N 1N4 

fcjjjt ►"! . 

KEY WORDS Operating system Command language Recursion Multics Ackermann’s function Towers of 
Hanoi 

The Multics operating system, 1 ' 2 currently available on a series of Honeywell 
machines, was developed starting in 1964 as a joint effort involving Project MAC of 
M.I.T., Bell Telephone Laboratories, and the computer department of General 
Electric Company, later taken over by Honeywell Information Systems, Inc. This 
^ operating system is very nicely structured, and it is intended for, and very well designed 
for interactive use. The command language, therefore, is also designed to make 
interactive use of the computer convenient. This is achieved through a combination of 
features, including the availability of powerful commands, the availability of standard 
and user-defined abbreviations, the availability of on-line documentation, and the great 
consistency in the use of arguments to the commands. 

In addition to containing a number of powerful commands for interactive use and 
immediate execution, the Multics command language is also a reasonably complete 
programming language, since there is provision in IVlultics for defining files, called 
segments in Multics, containing commands; these commands are executed when such a 
segment is invoked by giving its name as the first argument to the exec^com processor. 
These so-called exec_com segments may have parameters, which are passed by value, 
and they may be called recursively. An extensive set of so-called active functions is 
provided in the operating system; these active functions allow certain operations, 
including arithmetic ones, to be performed, and they permit access to many system 
values and parameters ranging from the time of day and the electronic mail system to 
such things as the search rules for locating segments in the hierarchical file directory 

Commands in exec^com segments fall into two categories: the regular Multics 
commands, and commands which can occur only in exec_com segments. The latter, 
which are distinguished by being preceded by an ampersand, include the Scprin’t 
command, and the Sdf command, which permits conditional excecution of commands 
but which, regrettably, may not be nested. 

m the exec ~ com fac ihty is the fact that there are no facilities for declaring 
ocal variables, and even the facilities for declaring and using non-local variables are 
convenient, and very poorly documented. For example, since it is apparently 
umed that most exec^com processing will be concerned with strings, if the value 
igne to a variable by means of the value$set command is an arithmetic expression, 
command assigns to the variable the string representing the expression (which may 

• later Using the active function value, rather than the value of the 
^pression. 


0038-0644/ 8i /070741 -04$0 1 . 00 
© 1981 by John Wiley & Sons, Ltd. 


Received 12 November 1980 


. ■ 

■ • - 


J $ 


afty. 


Hi 


ife 


tv - 






• • 




742 a. w - colijn 

In spite of its weaknesses as a programming language, the command language, 
together with the execucom processor, is a powerful programming facility. Of course, 
the validity of this claim may be proven or illustrated in a number of ways. Following an 
earlier paper, 3 we use two examples as illstrations: the Towers of Hanoi problem and 

Ackermann’s function. ... 

The well-known Towers of Hanoi problem 3 has an elegant recursive solution, as 
follows. In order to move n discs from stack 1 to stack 3, say, begin by moving the top 
n - 1 discs from stack 1 to stack 2, according to the rules, and provided that n > 1 . Then 
move the remaining, largest disc from stack 1 to stack 3, and finish up by moving the 
n-\ discs from stack 2 to stack 3, again according to the rules, and again provided that 

n> The solution using the exec-com facility of Multics, shown in Figure 1, follows the 
above recursive solution directly. The segment named Hanoi. ec (where the suffix .ec 

& This is the segment Hanoi. ec; it has four arguments 
& representing the number of discs and the source, 

& intermediate and destination stacks. Example: 
fif ec Hanoi 4 “s” “i” “d” 

& 

& command-line off 

&if [greater & 1 1] &then ec Hanoi ( minus &1 1] &2 &4 &3 
&print move disc &1 from &2 to &4 

&if [greater &1 1] &then ec Hanoi [minus & 1 1] &3 &2 &4 
Figure 1. Multics exec-com segment for the Towers of Hanoi problem 

indicates the type of the file to the operating system) contains the necessary commands, 
with the first one, 

SccommandAine off 

being used only to suppress the automatic printing of Multics commands as they are 
being executed. It is worth noting that references to formal parameters are made by 
their positions— thus &1, &2, &3 and & 4 denote the four formal parameters— and that 
ec is (an admissible abbreviation of) the Multics command to execute an exec-com 
segment. Hence the parts of the last and third-last lines of Figure 1 which read 

ec Hanoi [ minus &1 1] ... 

are recursive calls of the execucom segment Hanoi, with the first argument, the number 
of discs, reduced by 1 . The Sprint statement causes the string which follows on the 
same line to be printed, but only after parameter substitution has taken place. 

Ackermann’s function 3 ’ 6 ' 7 is a doubly recursive function which may be defined by 

' 71+ 1 if 771 = 0 

A(m,n) = A(m-l,t) if m > 0, tz = 0 

A(m-l,A(m,n-l)) if m>0,n>0 

A Multics command language program for Ackermann’s function cannot follow the 
definition directly, since exec-com segments cannot be used as functions, and they 
cannot, therefore, be used as arguments to exec-com segments or to active functions. A 
Multics command language program to compute Ackermann’s function, consisting o 
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four exec-£om segments, is shown in Figure 2. The segment Ackermann.ec plays a co- 
ordinating role. It creates a segment, here called zvhocares, in which the value$set 
command may allocate variables; in this case only one variable, A, is used. It then 
invokes the segment pi .ec which starts the actual computation. Upon return from pi 
the value A of Ackermann’s function is printed using the value$dump command. The 
segment p0.ee is used to circumvent the problem, mentioned above, that all 
assignments using value$set are string assignments: since arguments are passed by 
value, the value of the argument &1 is assigned to A. 



This is the segment Ackermann.ec ; 

& it has two non-negative integer 
& arguments. Example of use: 

& ec Ackermann 2 3 
& 

. & command-line off 
value$setseg whocares 
ec pi &1 &2 
value$dump A 
& command-line on 

& This is the segment p0.ee; it has 
& one argument and is used to make 
& assignments to the variable A. 

& 

& command-line off 
valueSset A &1 

& This is the segment pi .ec; it has 
& two arguments , it distinguishes 
& between the cases of Ackermann’ s 
& function, and it deals with the 
& simpler cases. 


' 


& command-line off 

&if [nequal &1 0 ] &then ec pO [plus &2 1] 
&if[nequal & 1 0} & then &quit 
& if [ngreater &2 0] 

& then ec p2 &1 [ minus &2 1] 

&else ec pi [minus & 1 1] 1 


S’ This is the segment p2.ee; it has 
& two arguments and it deals with the 
& case m> 0, n>0. 

& 

& command-line off 
ec pi &1 &2 

ec pi [minus & 1 1] [value A] 

Figure 2. Multics exec-com segments for Ackermann’s function 

The segmentpl.ee separates the three cases and deals with the simpler ones. Thus 
Am rSt tW ° ^ statements deal with the first line of the definition of the function, i.e. 
(0,n) = m+ 1, after which the 8cquit statement effects a return. Note in passing that 
statements are use d because of the absence of a compound statement facility, 
311 t atthe active function names nequal and ngreater stand for ‘numerically equal’ and 
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‘numerically greater than’ respectively. The final three lines of the segment distinguish 
between the remaining cases, dealing with the more complicated one with a call to p2.ec, 
and with the simpler one through a recursive call to p\.ec. Finally, since execucom 
segments cannot be used as functions, the segment pl.ec deals with the most 
complicated case in two steps: It first computes A(m, n — 1 ) by a call to pi .ec, and then it 
uses the computed value in another call to pl.ec to obtain the final result. 

It remains to be observed that although few people would use the execucom facility for 
computing Ackermann’s function, or solving the Towers of Hanoi problem, the facility 
is very useful, and it is used frequently, especially for systems-related tasks. Of 
particular interest in this context are exec^com segments with the name start-up. ec. 
These are invoked automatically when a user logs in and they allow the creation of 
convenient and ‘friendly’ environments within Multics. 


Table I. Comparative timings for Multics control language and comparable PL/1 
programs on a Honeywell level 68 DPS 



Multics control 
language (s) 

PL/1 (s)— includes 
compilation, dynamic linking 
and execution 

Towers of Hanoi 

2 discs 

0-272 

1-158 

3 discs 

0-724 

1-191 

4 discs 

1-522 

1-256 

5 discs 

3-206 

1-296 

Ackermann’s function 

A(2, 0) 

0-861 

1-166 

A(2, 1) 

2-362 

1-169 

A(2, 2) 

4.501 

1-172 

A(2, 3) 

7-454 

1-172 

A(2,4) 

— 

1-172 


Note finally that, as shown in Table I, the command-language solutions to the two 

problems are competitive in terms of virtual cpu time (though the measurement of this 

tends to be inaccurate in time-sharing environments) with the more conventional 

solutions using PL/1 (say), so long as the arguments are small. 
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Identification 

Multics Command Language 

W. H. Southworth, G. Schroeder, R. Sobecki, D. Eastwood 

Purpose 

The Multics Command Language provides the user with a concise means of 
expressing his wishes to the Multics system. The language and 
Implementation are based on the work and suggestions of L. Peter Deutsch, 
E. L. Glaser, R. M. Graham, C. N. Mooers , J. H. Saltzer, and C. Strachey. 

Introduction 

Most time-sharing systems provide the user with various services which 
may be invoked from his console by means of "commands" to the operating 
system. A small number of time-sharing systems go beyond this and allow 
any user to define (with varying degrees of ease) his own commands, which 
may be used in exactly the same way as the system supplied commands . 
Nearly all command programs, whether user defined or system provided, 
require additional information, which must be supplied by the user, 
before they can complete their function. Some systems require that every 
command program directly interrogate the user for the additional 
information it needs. A more general method is to accept "arguments" in 
addition to the command name, at the time the command is issued by the 
user. These arguments are then passed on to the command program by the 
system. This approach permits great flexibility in the design of command 
programs. Information may be supplied by arguments, interrogation or a 
combination of both. 

Issuing a command is analogous to executing a function or subroutine call 
in a language such as PL/1 or FORTRAN. With this view, the name of the 
command is simply the name of a command program to be either interpreted, 
if it is a user defined macro (see BX,1.01 for a description of the Macro 
facility) , or executed if it is the name of an entry point in an 
executable segment which conforms to Multics standards (as defined in 

BD. 7.02) . The arguments are either used in the expansion of the macro or 
passed to the executed procedure in the standard manner. The link between 
the issuance of the command by a user and the calling of the command 
program is the command language interpreter. It performs many of the 
functions of a compiler, principally, parsing the command (which is 
initially a character string) into its basic elements (e.g., command name 
and arguments) and formatting the arguments for use by the command 
program. Finally, the command language interpreter calls the macro 
expander if the command name is the name of a macro or calls the command 
program directly. 

The Command 

A command is a sequence of zero or more elements. The first element is 
interpreted as the name of the command program and any additional 
elements are arguments. The normal command program will expect input 
arguments which are fixed length character strings, and return a value 
which is a varying character string. If the command program does not 
expect arguments in this form the command language interpreter, the 
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Shell, will convert the type of the arguments according to information 
contained in the symbol table for the command program. The elements of 
command are separated by spaces and terminated by a semicolon or a new 
line character. For example, to change the name of a file from "a" to 
"b", using the change_name command, a user would type 

(1) change_name a b 

Elements 

The simplest type of element is a string of characters not containing any 
spaces or other characters reserved by the command language. The 
semicolon and new line characters are reserved. Other reserved characters 
will be identified as they are encountered. The three elements in example 
1 . at the end of the previous section are the simple character strings 
" change_name ", " a " , and " b " . 

Any element (or part of an element) may be a command. The user can tell 
the interpreter to evaluate an element as a command by surrounding the 
element with brackets (which are reserved characters) . For example in 

(2) change_name [oldest file] b 

the second element is a command. When an element is evaluated is a 
command, the result of that evaluation (i.e., the returned value of the 
function) replaces the original element. Suppose that the command 
" oldestf ile " returns as its value the name of the oldest file in the 
users' directory, then example 2 changes the name of the oldest file to 
"b" . In this case, the first argument to the command program change name 
is the character string returned by the command program "oldestf ile" and 
the second argument is the character string "b" . 

Note that the spaces before and after the brackets are necessary to 
indicate that the result of "oldestfile" is an element and not a portion 
of an element. Suppose that the user had a program "me" which returned as 
its value his default working directory, (e,g., "me" would return a 
character string of the form ">user_dir_dlr>Southworth.MAC" ) . While 
working in some other directory the user might link to a file in his 
default directory by typing 

(3) link [me] >test . epl 

This command consists of two elements, the character string "link" and 
the result of the command program "me" concatenated with the character 
string ">test.epl". Similarly a command of the form 

(4) link [me] >[ filename 17] 

would consist of only two elements, where the second element is formed 
using the values returned by the two command programs "me" and 
"filename". Note that the command "filename" has one argument, the 
character string "17". 

Sometimes it is necessary to use a reserved character without its special 
meaning. For example, a command name might contain an imbedded space. The 
characters quote and left and right accent are reserved for this purpose. 
Reserved characters within any string of characters surrounded by quotes 
or accents, will be treated as ordinary characters. For example, 

( 5 ) ' change name ' a b 
change" "name a b 



"change name" a b 
change ' ' name a b 

are all acceptable methods for executing a command whose name contains an 
imbedded space. Also, since quotes and accents are reserved characters it 
may be desirable to suppress the special meaning of one or the other. 

This may be done by surrounding quotes with accents, and accents with 
quotes. For example, the operator could issue the command 

broadcast "Don't do anything!" 

Active, Neutral, and Empty Commands 

There are three types of commands which may appear in elements: active, 
neutral and empty commands . In order to understand how these three types 
differ it is necessary to have a basic knowledge of the scanning and 
interpretation algorithm of the shell. A command line is scanned from 
left to right. The shell maintains a pointer which indicates its current 
position in the line. Whenever a command has been completely scanned it 
is evaluated (i.e., the command program is executed). For example in 

( 6 ) change_name a b ; 


when the pointer has reached the indicated location the shell will 
recognize that the end of a command has been reached and call the command 
program " chang e_name " . In the case of an element which is a command, 
nothing to the right of the element will be scanned until after the 
command element has been executed and its value has been inserted back 
into the command line. For example, in 

(7) change_name [oldestfile] b; 


when the pointer has reached this point the command program "oldestfile" 
will be called. If the returned value is "xyz", the transformed command 
line is 

( 8 ) chang e_name xyz b ; 


Note that the pointer is set to the beginning of the inserted value. This 
is important because the returned value will now be scanned in the same 
manner as the original command element. If "oldestfile" had returned the 
string " [myoldest] " , then the scanning pointer would have encountered 
this string as a command because of the brackets and executed the command 
"myoldest" . 

The type of command in the previous examples, which returns a value which 
is rescanned we will define as an "active command" . The command language 
recognizes two other kinds, a "neutral command" and an "empty command". A 
command preceded by "| [" rather than | | [' is said to be "neutral". Its 
value is not rescanned. This is particularly useful in defining certain 
macros. If our previous example with "oldestfile" had read 

(9) change_name | [oldestfile] b; 

and "oldestfile" had returned the string "[myoldest]", then this value 
would have been inserted into the command line and the scan pointer set 
to the next character after the inserted character string, i.e.. 



( 10 ) 


change_name [myoldest] b 

A 


In this case the inserted string would not be recognized as a command and 
"change name" would be called with " [myoldest] " as its first argument. An 
"empty" command is preceded by "| | [". After an empty command is executed 
its value is thrown away. 

The vertical bar is a reserved character only in the context of " | [ " or 
"| | [”• An easy way to remember the three types of commands is to think of 
a command as performing the three actions: evaluation, insertion, and 
reevaluation. A single vertical bar suppresses reevaluation leaving 
evaluation and insertion, while a double vertical bar suppresses 
reevaluation and insertion leaving only the first evaluation. 

Iteration 

Sometimes the user wishes to repeat a command with one or more elements 
changed. The iteration facility of the command language is provided for 
economy of typing in this case. The "iteration set" is a set of zero or 
more elements enclosed by parentheses (parentheses are reserved 
characters) . If it contains no elements it is ignored. Otherwise, each 
element of the set will, in turn, replace the entire set in the command 
line. For example 

(11) print (a b c).epl 

is equivalent to the three commands 

print a.epl; print b.epl; print c.epl 

More than one iteration set may appear in a command. All possible 
combinations will be executed. For instance, the compound command 

(print delete) xyz ( . epl .eplbsa); 

would expand into the commands : 

print xyz. epl 
print xyz. eplbsa 
delete xyz . epl 
delete xyz. eplbsa 

Nested iteration sets behave in exactly the same manner as unnested sets. 
Evaluation of parentheses occurs from the outside in. The principal use 
of nested iteration sets is to reduce typing when subsets of an element 
are repeated. For example 

(12) make_directory >user_dir_dir> ( (Southworth Martin). MAC Stone. GE) 

would make three directories 

>user_dir dir>Southworth.MAC 
>user dir dir>Martin.MAC 
>user_dir_dir>Stone . GE 

Summary of Command Language Syntax 

The Multics Command Language contains the following syntactical elements . 


command line 



the character string representation of a command or sequence of 
commands . 

command 

a sequence of zero or more elements separated by spaces (in the 
command line) . The first element is taken as the command name and 
additional elements as arguments. 

iteration set 

a sequence of zero or more elements, enclosed by parentheses, which 
are Inserted in turn in the command for evaluation. 

command program 

either a defined macro to be recognized and expanded by a macro 
expander program, or executable machine instructions, whose name 
represents an entry point in a segment which conforms to Multics 
standards (as defined in BD.7.02). 

element 

the basic component of a command; it may represent a command name, 
or argument . 

active command 

a sequence of zero or more elements surrounded by brackets (it is 
not necessary to enclose the character string typed in at the user's 
console with brackets, in this case brackets are assumed) . The 
character string within the brackets is treated as a command - it is 
evaluated, its value is inserted into the command line and its value 
is rescanned as part of the command line. 

neutral command 

a sequence of zero or more elements surrounded by "| [" on the left 
and "] " on the right which is evaluated, as a command line, but is 
not rescanned. 

empty command 

a sequence of zero or more elements surrounded by " | | [ " on the left 
and "]" on the right which is evaluated. Its value is thrown away. 

literal string 

a character string surrounded by quotes or balanced left and right 
accents. Its value should be taken literally, i.e., reserved 
characters within the string should not be recognized for their 
special meaning. 

semicolon 

denotes the end of a command and the beginning of another command of 
the same type . 

new line 

new line characters within the command string passed to the command 
language interpreter are ignored if encountered in the scan of the 
command line. This should not be confused with the fact that the new 
line character may serve as a delimiter for whatever program called 
the interpreter . 

Imp 1 ement at i on 

The command language interpreter, the Shell, is normally driven by the 
Listener. The shell provides the necessary parsing to process a character 
string as a command. The Listener can be conceptually described as 



[ [read_line] ] ; listener 

Its function is to listen for requests in the form of command lines typed 
in at the user console. In the above command language description, the 
listener reads in a line from the console, evaluates the line as a 
command, and re-calls itself to repeat the function. In actuality this is 
usually accomplished by a Multics procedure which calls the shell which 
accepts as its single argument a character string (fixed length or 
varying) to be evaluated as a command. 

Formal Description of the Multics Command Language 

The following Backus-Naur description formally defines the syntactic 
components of the Command Language. For simplicity we have not provided 
definitions for the ASCII characters, based on the assumption that the 
alphabet is not open to design changes. If a construct is enclosed in 
parentheses it is to be interpreted as zero or more occurrences of that 
construct . 

<command sequence> ::= <command> (<semicolon> <command>) 

<command> ::= <element list> 

<element list> ::= <element> (<spaces> <element list>) 

<element> ::= <element component> (<element>) 

<element component> ::= <function> | citeration set> 

<literal string> | <unreserved character> 

<function> ::= <active function> | cneutral function> 

<empty function> 

<active function> <left bracket> <command> <right bracket> 

<neutral function> ::= <vertical bar> <left bracket> 

<command> <right bracket> 

<empty function> ::= <vertical bar> <vertical bar> <left 

bracket> <command> <right bracket> 

<iteration set> ::= <left paren> <element list> <right paren> 

<literal string> ::= <quoted string> | <balanced quoted string> 

<quoted string> ::= <quote> cbalanced quoted string> <quote> | 

<quote> <unquoted character string> <quote> 

cbalanced quoted string> cleft accent> cbalanced quoted 

substring> cright accent> 

cbalanced quoted substring> ::= ccharacter string not containing ' or '> 

| cbalanced quoted string> 
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